WTF Bites

[LaoC]

@Tsaukpaetra said in WTF Bites:

@cvi said in WTF Bites:

"I can go for miles if you know what I mean!"

I got my unisex screw cap on, just brushed, ready for anything you sigg fuggs come up with!

[nerd4sale]

@izzion said in WTF Bites:

How the hell are you all so hard on your mice? I play MMOs and am a compulsive camera fiddler, and I get 3 years out of a $60 mouse easily. I think the current one is actually older than that.

I wonder about that as well. I don't think I have broken a mouse ever.

My mice usually get replaced only when there's some hardware change:
from serial/25 to serial/9
from serial/9 to PS/2
from PS/2 to wireless ergonomic PS/2
from wireless ergonomic PS/2 to USB
from ball to red laser
from red laser to invisible laser
from wired to wireless wifi-ish
from wireless to wired (wifi-ish wireless mouse only worked on some very specific HP laptop models)
from wired to wireless USB
from wireless USB to wired (USB mouse just doesn't feel "right", and I got tired of replacing batteries every other week)

I now have a whole collection of cheap brand-name mice, and they all still work.
Logitech, Microsoft, HP, Dell and all in the EUR 5-10 range.

I did flirt a bit with those ergonomic mice, but I never really liked any of them except for that one Logitech PS/2 one, which unfortunately does not work with a PS/2 to USB adapter.

[Zerosquare]

You're the anti-.

I wonder what would happen if both of you were to meet one day...

[Applied Mediocrity]

@Zerosquare

@Benjamin-Hall said in In other news today...:

Feb 26, 2022  /  tech

Supermassive black holes will smash into each other and warp space...

Two massive black holes will merge in 10,000 years, in a collision that will send ripples across the universe, a new study finds.

[topspin]

I opened Excel because of another post .

It should be already signed in because I vividly remember opening Word last year, habitually dismissing some stupid "we O365 now, please do the needful" dialog, and then not being able to save (silently doing nothing without getting an error message). Until I realized that signing in was mandatory, but error messages on failure are not, so . (Also, signed in or not, it does display my name in the title bar. Why?)

Anyways, what was my point again...? Ah yes, it told me that it doesn't work for some reason or another with "shared license" (whatever that means for an enterprise account), so I decided to not repeat my earlier mistake and tried to sign in again, first. This was the result:

Um, what? I guess so, this is a shared server after all. You have heard of multiple user accounts, I assume?

Anyways, actually just restarting Excel fixed the problem. Microsoft's weapon of choice, reboot everything.

[aitap]

@topspin said in WTF Bites:

I opened Excel

It should be already signed in

Imagine reading this ${a few} years ago. "What do you mean, sign in into a spreadsheet? Is there a macro that asks the password? "

[topspin]

@aitap said in WTF Bites:

@topspin said in WTF Bites:

I opened Excel

It should be already signed in

Imagine reading this ${a few} years ago. "What do you mean, sign in into a spreadsheet? Is there a macro that asks the password? "

I still feel the same about it. O365 is the dumbest shit ever.

[HardwareGeek]

@topspin Maybe. Signing into a browser is of approximately equal stupidity, IMHO.

[Tsaukpaetra]

@aitap said in WTF Bites:

@topspin said in WTF Bites:

I opened Excel

It should be already signed in

Imagine reading this ${a few} years ago. "What do you mean, sign in into a spreadsheet? Is there a macro that asks the password? "

I relish the days where it simply assumed your name from your user account.

And then the fire nation attacked.murders began

[Gąska]

@Tsaukpaetra reminds me.

My company is in the process of being eaten by a competitormerging with a larger company. As a side effect, we now have two AD domains, and two accounts to use for logging into the various systems. Each system is only connected to one of the accounts, of course, and the other doesn't work. That's not the WTF.

The WTF is Edge (). Obviously one of the accounts is used to log into the work laptop, and it's associated with the local profile. When you go to a website which asks for login, Edge helpfully offers to use Windows account credentials. Which is fine if it's actually the one you want, but in my situation, half the time it isn't. That's still not the WTF.

The WTF is that the first time you use it, if the login "succeeds" (403 Forbidden after credentials are accepted counts as "success"), it remembers it and never asks you again. Which, again, is fine if it's actually the one you want, but in my case it wasn't; I just clicked it out of habit. And once it remembers, it never forgets. Never. There's no option to use a different account. There's no option to erase data for just that one site. The only option is to erase all browsing data from all websites, which also erases most of the browser config. Who the fuck designed it like that!? And then they wonder why people avoid Edge like fire.

That's if you're a technical user. If you're non-technical, you wouldn't realize the login "succeeded" even though it actually didn't. You wouldn't realize you are using the wrong account. You wouldn't realize "scan fingerprint to access site" window was actually putting in the wrong credentials. You wouldn't realize you had to click this tiny "other options" link instead. You wouldn't realize Edge has remembered the wrong account and that's why the error keeps happening. You wouldn't realize the fact you were only asked for password the first time around is significant. To a non-technical user - such as the other new hire on my onboarding - it looked like a broken website that's broken because it's broken, and the only choice is to ask IT department to unbreak it for her. All because Edge doesn't give you an option not to remember the password.

I'm pretty sure this is the reason why onboarding instructions specifically mention this one website only works in Chrome and Firefox. It's far easier to say that than to explain the actual problem.

[Tsaukpaetra]

@Gąska said in WTF Bites:

this one website only works in Chrome and Firefox.

Yeah, at my current place Chrome and Edge really push push about using the single sign-on. This is impossibly annoying when, hey Microsoft, I don't want to use that account to log in!

I have to do all sorts of trickery involving incognito and specific sequences to get it to work right.

Thank $deity I only need to use that particular site once a week...

[Benjamin Hall]

@Tsaukpaetra To log into the Google Play Console for our business app, I have to use Firefox. Because Chrome (my daily driver) has a different google account synced and I can only log in to that account's console (which is empty, of course). That's all I use Firefox for, other than limited cross-browser testing.

[Bulb]

@Gąska said in WTF Bites:

I'm pretty sure this is the reason why onboarding instructions specifically mention this one website only works in Chrome and Firefox. It's far easier to say that than to explain the actual problem.

Using a different browser for things where you need to log in to a different account has been a standard operating procedure for many people I know since ages. I had two Chromium profiles for a while, but while they worked mostly nicely in Windows, they are a bit of pain in Linux and Firefox profiles are a bit of pain everywhere.

So I now use Chromium with company accounts, Firefox with personal accounts, and a containerized Firefox (the container has a special proxy set up, because the customer VPN is special) with customer accounts (that can also be a Firefox, because it does not see the other instance from the container).

And since my wife's company has split, she uses mostly Edge for the main work and one of the other browsers when she needs to log in to the systems with the parent company account.

[boomzilla]

@Benjamin-Hall said in WTF Bites:

@Tsaukpaetra To log into the Google Play Console for our business app, I have to use Firefox. Because Chrome (my daily driver) has a different google account synced and I can only log in to that account's console (which is empty, of course). That's all I use Firefox for, other than limited cross-browser testing.

I mean...you could create another Chrome profile that's synced to the account you want. Err...I guess they call them "people" now.

[Gribnit]

@boomzilla said in WTF Bites:

Err...I guess they call them "people" now.

I told you this would happen, and you didn't believe me.

[boomzilla]

@Gribnit still don't!

[Zerosquare]

Mar 3, 2022

Amazon Alexa compromise possible through own speakers

This isn't the artificial intelligence we were promised

Without a critical update, Amazon Alexa devices could wake themselves up and start executing audio commands issued by a remote attacker, according to infosec researchers at Royal Holloway, University of London.

By exploiting a now-patched vulnerability, a malicious person with some access to a smart speaker could broadcast commands to itself or to other smart speakers nearby, allowing said miscreant to start "smart appliances within the household, buy unwanted items, tamper [with] linked calendars and eavesdrop on the [legitimate] user."

[HardwareGeek]

@Zerosquare said in WTF Bites:

This isn't the artificial intelligence we were promised

[topspin]

@error_bot !xkcd listening

[error_bot]

xkcd said in https://xkcd.com/525/ :

I Know You're Listening

1807: Listening - explain xkcd

)

[topspin]

@error_bot bad bot!

[Gąska]

int main(int argc, char* argv[])
{
 int i=doargs(argc,argv);
 argc-=i; argv+=i;

I hate C programmers sometimes.

[cvi]

@Gąska said in WTF Bites:

I hate C programmers sometimes.

Without additional context ... what's wrong with that?

[Gribnit]

@cvi just hating them? No problems there, I advise it. I do not suspect that argc is passed by reference, tho.

[cvi]

@Gribnit said in WTF Bites:

just hating them? No problems there

Yeah, but there's a more concise way to say that.

I hate C programmers sometimes.

[Gąska]

@cvi

Zero additional context:

1. argc and argv are super similar to each other; with my imperfect sight, it took me several seconds to realize it's not a no-op. Even just putting these two statements on separate lines would make the code easier to read. But no, we still live in 1980s and disk space for source files is expensive.
2. In general, modifying arguments is a great way to make code hard to read.
3. doargs separates dash-dash-flag arguments from input-file-path arguments. This assumes there are no more flags after the first input file. This makes the program somewhat annoying to use in a terminal.
4. Or maybe not; haven't actually checked. Maybe it modifies argv array in-place to move flags before files. Which would be even worse.
5. There's no need to change argc or argv. They could simply do the subtraction on use, since they use them only once in the rest of the function.

Some additional context after I read what doargs actually does:

• Turns out #3 above is wrong. It doesn't interpret flags as files. It just refuses to work if the user doesn't put -- before input files. Even if there are no flags.
• But that doesn't mean it doesn't rewrite argv. It does, although for different purpose - argv[0] gets replaced with the output path, which by default isn't even part of the command line. Why this instead of making a global variable for it like with the other 10 configuration options? I have no idea. My bet is someone was feeling a little too clever.

[cvi]

@Gąska This rates "meh" on my scale of problem severity. The fact that whoever wrote doargs sucked at programming isn't apparent from your snippet. (Advancing argv like that is a bit of a warning sign, though.)

• For the better or worse, argc and argv are the conventional names. If you have a better set of names, go for it. I won't blame somebody for using the conventional names, though.
• Not sure why modifying arguments is special. They're just another set of variables.

FWIW, I wouldn't write things that way (and generally prefer a SSA style when feasible). But the snippet doesn't look that out of place.

[Gąska]

@cvi it's not about the names. It's about modifying the values of passed arguments. Instead of making new local variables. And modifying argv in particular is annoying because everybody expects argv[0] to always be the executable name and argv[1] through [argc-1] to be arguments as provided by the user. They're making the code harder to follow for no reason.

[Gribnit]

@Gąska said in WTF Bites:

everybody expects argv[0] to always be the executable name and argv[1] through [argc-1] to be arguments as provided by the user

Huh, more people than shell writers get to assume this? Fair enough. Still not a good enough reason to take off the Java condom.

[LaoC]

@cvi said in WTF Bites:

@Gąska This rates "meh" on my scale of problem severity. The fact that whoever wrote doargs sucked at programming isn't apparent from your snippet. (Advancing argv like that is a bit of a warning sign, though.)

Unless the target is some ultra-restricted embedded thing where this is probably one of the least weird optimizations, is not using getopt(3) in the first place.

[Bulb]

@Gąska said in WTF Bites:

@cvi

Zero additional context:

1. argc and argv are super similar to each other; with my imperfect sight, it took me several seconds to realize it's not a no-op. Even just putting these two statements on separate lines would make the code easier to read. But no, we still live in 1980s and disk space for source files is expensive.

Since argc is size of argv, putting the statements on the same line makes more sense to me logically. Because they are one operation. The names are also traditional and I am used to them, so the statement is completely obvious to me at first sight. Experience. Yes, it's a quirk of the language.

2. In general, modifying arguments is a great way to make code hard to read.

Except everybody (and the cat) does just that with argc and argv, exactly like this.

3. doargs separates dash-dash-flag arguments from input-file-path arguments. This assumes there are no more flags after the first input file. This makes the program somewhat annoying to use in a terminal.

I always assume flags must come before positional arguments, because half of the programs work that way.
Sometimes annoying, but common.

5. There's no need to change argc or argv. They could simply do the subtraction on use, since they use them only once in the rest of the function.

That would be completely unreadable, because unexpected. Skipping an argument – and you almost always skip at least argv[0] because of a Unix quirk – is commonly done exactly like here.

Some additional context after I read what doargs actually does:

• Turns out #3 above is wrong. It doesn't interpret flags as files. It just refuses to work if the user doesn't put -- before input files. Even if there are no flags.

Yeah, that's silly.

• But that doesn't mean it doesn't rewrite argv. It does, although for different purpose - argv[0] gets replaced with the output path, which by default isn't even part of the command line. Why this instead of making a global variable for it like with the other 10 configuration options? I have no idea. My bet is someone was feeling a little too clever.

That's even sillier indeed. And then the caller advances the argv pointer, so it does not seem to be reading the new argv[0] anyway.

@LaoC said in WTF Bites:

@cvi said in WTF Bites:

@Gąska This rates "meh" on my scale of problem severity. The fact that whoever wrote doargs sucked at programming isn't apparent from your snippet. (Advancing argv like that is a bit of a warning sign, though.)

Unless the target is some ultra-restricted embedded thing where this is probably one of the least weird optimizations, is not using getopt(3) in the first place.

Yes, this. The wheel already exists. No need to re-invent it. Except … well, getopt is a bit complicated, so many programmers out there think it's an overkill, start without, and then keep their mess when the argument processing gets more complicated and using getopt would have long paid off.

[Gąska]

@Bulb said in WTF Bites:

That's even sillier indeed. And then the caller advances the argv pointer, so it does not seem to be reading the new argv[0] anyway.

You missed the <abbr>. It's argv[i] that gets overwritten, and after the shift it becomes argv[0]. So not useless, but still very "silly", as you put it. I'm more inclined to use the word "retarded".

As for the argv-shifting being the usual style... This is exactly what I hate C programmers for. Anybody who isn't already used to that - ie. everyone who mostly codes in languages that aren't C, which is the vast majority of programmers - will get tripped by it. Even C++ programmers. Nobody does that except C programmers.

I always assume flags must come before positional arguments, because half of the programs work that way.

And I always avoid spaces and non-ASCII characters in file paths because half of the programs can't handle it. It's the same thing. Many programs are broken in the same way. So many that we just learned to assume everything is broken in that way, and habitually apply workarounds even if they're not needed. Doesn't make it any less broken.

[Bulb]

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

That's even sillier indeed. And then the caller advances the argv pointer, so it does not seem to be reading the new argv[0] anyway.

You missed the <abbr>. It's argv[i] that gets overwritten, and after the shift it becomes argv[0]. So not useless, but still very "silly", as you put it. I'm more inclined to use the word "retarded".

Yes, that's retarded.

As for the argv-shifting being the usual style... This is exactly what I hate C programmers for. Anybody who isn't already used to that - ie. everyone who mostly codes in languages that aren't C, which is the vast majority of programmers - will get tripped by it. Even C++ programmers. Nobody does that except C programmers.

I see it in C++ as well. It's somewhat natural for the iteration by advancing a pointer, and iteration by advancing an object designed to behave as pointer (which is what's going on here) and if the functions are short – or for main where the args are always read just once near the beginning.

Each language has its idioms that feel unnatural and unexpected for people coming from other languages.

I always assume flags must come before positional arguments, because half of the programs work that way.

And I always avoid spaces and non-ASCII characters in file paths because half of the programs can't handle it. It's the same thing. Many programs are broken in the same way. So many that we just learned to assume everything is broken in that way, and habitually apply workarounds even if they're not needed. Doesn't make it any less broken.

Agreed. There are conventions and libraries for argument parsing. There is no excuse for cobbling together shit instead.

[LaoC]

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

That's even sillier indeed. And then the caller advances the argv pointer, so it does not seem to be reading the new argv[0] anyway.

You missed the <abbr>. It's argv[i] that gets overwritten, and after the shift it becomes argv[0]. So not useless, but still very "silly", as you put it. I'm more inclined to use the word "retarded".

As for the argv-shifting being the usual style... This is exactly what I hate C programmers for. Anybody who isn't already used to that - ie. everyone who mostly codes in languages that aren't C, which is the vast majority of programmers - will get tripped by it. Even C++ programmers. Nobody does that except C programmers.

I always assume flags must come before positional arguments, because half of the programs work that way.

And I always avoid spaces and non-ASCII characters in file paths because half of the programs can't handle it. It's the same thing. Many programs are broken in the same way. So many that we just learned to assume everything is broken in that way, and habitually apply workarounds even if they're not needed. Doesn't make it any less broken.

It's called POSIX-conforming. getopt is just a sensible superset of that which happens to allow options after operands.

Non-C programs don't exactly do better in this regard though. Java programmers like to use that awful single-dash-long-option syntax otherwise popular only with the openssl weirdos while the Go folks tend to go for fat binaries that need dozens of non-option verbs and additional options to differentiate function. Perl's de facto standard Getopt::Long is mostly indistinguishable from getopt while Python and Ruby seem to be similar with ideas of their own just regarding option bundling.

Still slightly less of a mess than writing your completely custom commandline parser including idiosyncratic globbing as is common on certain other OSes.

[Bulb]

@LaoC said in WTF Bites:

while the Go folks tend to go for fat binaries that need dozens of non-option verbs and additional options to differentiate function

I'd say it was version control systems, and especially git, that popularized that.

[Gąska]

@Bulb said in WTF Bites:

I see it in C++ as well.

ITYM C with Classes. When you give a C programmer a language where C code is a valid program, they'll continue to write C.

It's somewhat natural for the iteration by advancing a pointer

Except this kind of iteration is itself unnatural. Especially when you have element count rather than a delimiter.

Ever noticed that C programmers love to use linked lists even when they don't make much sense? They're simply addicted to pointer arithmetic.

---

On an unrelated note. TIL calling main() inside a program is valid C, but technically invalid C++.

[Gąska]

@LaoC said in WTF Bites:

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

That's even sillier indeed. And then the caller advances the argv pointer, so it does not seem to be reading the new argv[0] anyway.

You missed the <abbr>. It's argv[i] that gets overwritten, and after the shift it becomes argv[0]. So not useless, but still very "silly", as you put it. I'm more inclined to use the word "retarded".

As for the argv-shifting being the usual style... This is exactly what I hate C programmers for. Anybody who isn't already used to that - ie. everyone who mostly codes in languages that aren't C, which is the vast majority of programmers - will get tripped by it. Even C++ programmers. Nobody does that except C programmers.

I always assume flags must come before positional arguments, because half of the programs work that way.

And I always avoid spaces and non-ASCII characters in file paths because half of the programs can't handle it. It's the same thing. Many programs are broken in the same way. So many that we just learned to assume everything is broken in that way, and habitually apply workarounds even if they're not needed. Doesn't make it any less broken.

It's called POSIX-conforming.

Your link describes how to write help text, not how to parse arguments.

Non-C programs don't exactly do better in this regard though.

They do. By not modifying arguments halfway through the function. The only other language I'm aware of where argument shifting is the convention is Bash, and as would put it, everything in Bash is terrible.

[LaoC]

@Gąska said in WTF Bites:

@LaoC said in WTF Bites:

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

That's even sillier indeed. And then the caller advances the argv pointer, so it does not seem to be reading the new argv[0] anyway.

You missed the <abbr>. It's argv[i] that gets overwritten, and after the shift it becomes argv[0]. So not useless, but still very "silly", as you put it. I'm more inclined to use the word "retarded".

As for the argv-shifting being the usual style... This is exactly what I hate C programmers for. Anybody who isn't already used to that - ie. everyone who mostly codes in languages that aren't C, which is the vast majority of programmers - will get tripped by it. Even C++ programmers. Nobody does that except C programmers.

I always assume flags must come before positional arguments, because half of the programs work that way.

And I always avoid spaces and non-ASCII characters in file paths because half of the programs can't handle it. It's the same thing. Many programs are broken in the same way. So many that we just learned to assume everything is broken in that way, and habitually apply workarounds even if they're not needed. Doesn't make it any less broken.

It's called POSIX-conforming.

Your link describes how to write help text, not how to parse arguments.

The arguments following the last options and option-arguments are named "operands".

Non-C programs don't exactly do better in this regard though.

They do. By not modifying arguments halfway through the function.

I thought it was "flags must come before positional arguments" that you considered broken.

[cvi]

@Gąska said in WTF Bites:

everybody expects argv[0] to always be the executable name and argv[1] through [argc-1] to be arguments as provided by the user.

The fact that it doesn't maintain argv[0] is problematic, agreed. That said , it's not uncommon for e.g. frameworks to do something like this (perhaps with less suck in the implementation). Command line arguments are first passed to the framework code, and the framework will inspect the arguments for options it knows, and then strips them out such that the rest can be processed by the application-code. (But argv[0] should still be the executable path, and [1.. adjusted argc-1] the application's command line options).

@Gąska said in WTF Bites:

Except this kind of iteration is itself unnatural. Especially when you have element count rather than a delimiter.

Again, for the better or worse, C++ frequently uses iterators/iterator ranges, which you iterate by incrementing/advancing an iterator until you reach your target. Pointers are just a special instance of that. With that I'd claim the exact opposite, this is very common in C++.

[Medinoc]

@Gąska said in WTF Bites:

Non-C programs don't exactly do better in this regard though.

They do. By not modifying arguments halfway through the function. The only other language I'm aware of where argument shifting is the convention is Bash, and as would put it, everything in Bash is terrible.

It's not quite "halfway through the function" if it's right at the start. It's a statement that says, "For this program, the only arguments left are the ones not processed yet".
But you're right in that this practice is quite associated to Bash (and other, similar shells). I think in Shell programming, it's even taught this way.

[dkf]

@Medinoc said in WTF Bites:

I think in Shell programming, it's even taught this way.

The shift command doesn't touch $0.

But it's got so many other weirdnesses about it that I'd recommend not writing programs in shell, not even if you think you know what you're doing.

[Bulb]

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

I see it in C++ as well.

ITYM C with Classes. When you give a C programmer a language where C code is a valid program, they'll continue to write C.

No. I mean C++ simply using iterators. Many functions that take (some_iterator begin, some_iterator end) then proceed to iterate over the range by for(; being != end; ++begin), abusing the begin argument as the iterator.

And they use this kind of iteration because the range for—and 99% of functors you'd use in a saner language instead—were crippled by the lack of a range (what iterators mean in other languages) until C++20. And a lot of code either predates C++20, or still needs to build with compilers predating C++20, so it still can't use std::range::range & co.

It's somewhat natural for the iteration by advancing a pointer

Except this kind of iteration is itself unnatural. Especially when you have element count rather than a delimiter.

Yes, with size it is easier to iterate by index.

Ever noticed that C programmers love to use linked lists even when they don't make much sense? They're simply addicted to pointer arithmetic.

Because for many things, pointer arithmetic is all they've got. And when you have a hammer…

[PleegWat]

@Gąska said in WTF Bites:

And I always avoid spaces and non-ASCII characters in file paths because half of the programs can't handle it.

That's more of a shell script problem. On unix this works correctly by default because arguments are split by the caller. Might be different on Windows of course, though I wouldn't expect so because many common paths contain spaces already.

That said, I'm also guilty of using getopt (or more commonly getopt_long) and modifying argc/argv afterwards. Then proceeding into a lookup table of command words (in the new argv[0]) mapping to functions which take the tail of the argument vector.

[topspin]

@PleegWat said in WTF Bites:

Might be different on Windows of course, though I wouldn't expect so because many common paths contain spaces already.

It is, indeed, different. Arguments are passed as one command line string, the CRT uses GetCommandLine to split it into argc/argv. And of course there's at least 3 different conventions for escaping. Which shouldn't matter if it's handled under the hood, but does when incompatible ones clash.

[dkf]

@topspin said in WTF Bites:

And of course there's at least 3 different conventions for escaping. Which shouldn't matter if it's handled under the hood, but does when incompatible ones clash.

It depends mostly on which C/C++ runtime you're using, as different runtimes have different parsing rules/bugs. And a few snowflakes decide that they want to do their own thing and manage to screw the pooch for a lot of other code; I'm looking at you, START, you inconsistent piece of shit.

[Bulb]

@dkf said in WTF Bites:

@topspin said in WTF Bites:

And of course there's at least 3 different conventions for escaping. Which shouldn't matter if it's handled under the hood, but does when incompatible ones clash.

It depends mostly on which C/C++ runtime you're using, as different runtimes have different parsing rules/bugs. And a few snowflakes decide that they want to do their own thing and manage to screw the pooch for a lot of other code; I'm looking at you, START, you inconsistent piece of shit.

Well, programs that use main (or wmain) get the arguments split by GetCommandLine implicitly (and then GetCommandLine slightly differs between the runtime version), but programs that use WinMain or wWinMain get the one string and if they chose to use something else then GetCommandLine, they can do whatever thing they shouldn't be doing.

[Gribnit]

@Bulb said in WTF Bites:

@LaoC said in WTF Bites:

while the Go folks tend to go for fat binaries that need dozens of non-option verbs and additional options to differentiate function

I'd say it was version control systems, and especially git, that popularized that.

Nope, blame busybox. Go is closer to embedded systems.

[hungrier]

@topspin said in WTF Bites:

@error_bot bad bot!

You just gotta know how to manipulate it

@error_bot xkcd inconvenience exploits

[error_bot]

xkcd said in https://xkcd.com/1807/ :

Listening

­

(via https://www.explainxkcd.com/wiki/index.php?search=inconvenience+exploits&title=Special%3ASearch&fulltext=1)

[Gąska]

@LaoC said in WTF Bites:

@Gąska said in WTF Bites:

@LaoC said in WTF Bites:

@Gąska said in WTF Bites:

@Bulb said in WTF Bites:

That's even sillier indeed. And then the caller advances the argv pointer, so it does not seem to be reading the new argv[0] anyway.

You missed the <abbr>. It's argv[i] that gets overwritten, and after the shift it becomes argv[0]. So not useless, but still very "silly", as you put it. I'm more inclined to use the word "retarded".

As for the argv-shifting being the usual style... This is exactly what I hate C programmers for. Anybody who isn't already used to that - ie. everyone who mostly codes in languages that aren't C, which is the vast majority of programmers - will get tripped by it. Even C++ programmers. Nobody does that except C programmers.

I always assume flags must come before positional arguments, because half of the programs work that way.

And I always avoid spaces and non-ASCII characters in file paths because half of the programs can't handle it. It's the same thing. Many programs are broken in the same way. So many that we just learned to assume everything is broken in that way, and habitually apply workarounds even if they're not needed. Doesn't make it any less broken.

It's called POSIX-conforming.

Your link describes how to write help text, not how to parse arguments.

I read the page to the end. You are right but for the wrong reasons. It's annoying.

Non-C programs don't exactly do better in this regard though.

They do. By not modifying arguments halfway through the function.

I thought it was "flags must come before positional arguments" that you considered broken.

I consider all of the stupid habits of C programmers to be broken. And POSIX sanctioning "this kind of broken behavior is fine" doesn't make it any less broken.

But modifying input arguments for no reason is worse than overly strict command line parsing, yes.