Hacker News Reader

Comment by mortenlarsen | Hacker News Reader

OpenBSD has handled this case for some years. I do not know if there was any breakage or fallout from this.

https://github.com/openbsd/src/commit/74212563870067f5b1e271...

That's not a bad precedent for saying it shouldn't break much of anything if it's done. I also love the name of the label for handling the error condition there.

Slightly funnier would be "harmful"

> OpenBSD has handled this case for some years. I do not know if there was any breakage or fallout from this.

The other thing about OpenBSD is that when they make a change to their OS, they also go through to make sure all the (third-party) ports/packages:

* https://cvsweb.openbsd.org/ports/

* https://github.com/openbsd/ports

do not break. So they're create patches for the software and and submit them upstream.

FWIW, Windows (MSVC) also guarantees "argc > 0" and non-empty argv with non-empty argv[0]. It also returns EINVAL if execve validation fails.

Windows doesn't have argv at all, it uses single string as cmdline arguments.

The C runtime bridges that gap. https://docs.microsoft.com/en-us/cpp/cpp/main-function-comma...

At the kernel level, yes. But they are talking about CRT, which parses the command line and makes argv from user space, if your linker is set up to have a main() and not WinMain.

That is why they put MSVC in parens.

Thanks for answering my next question, how much world of hurt would be involved with this solution in terms of breaking userspace.

Kind of insane how Linux kernel developers didn't test and resolve this in a similar manner before this became an issue.

argc==0 is a well known part of the API, even if not everyone handles it correctly. I guarantee that >95% of kernel developers (if not 100% of them) understand this design and its flaws.

Reply on news.ycombinator.com