4 ms·

This results in an argc of 0 in the a.out program: char* args[] = {NULL}; execv("./a.out", args); If someone did this by accident (as it's a programming e

This results in an argc of 0 in the a.out program: char* args[] = {NULL}; execv("./a.out", args); If someone did this by accident (as it's a programming error) then they should be told, instead of the unhelpful exit. That's my point.

tptacek 5y ago
The point of exit codes is that they're straightforward for programmers to extract, rather than error messages, which require the programmer to capture and parse stderr. So, no, I don't think you've rescued this very bad argument.
- ajiknight 5y ago
  I don't think this is a bad argument at all. It wouldn't kill anyone to include a brief stderr worthy message along with the exit. Especially when, and correct me if I'm wrong, code 126 is pretty vague here. "Command not executable" doesn't seem even correct to me.
  - tptacek 5y ago
    The entire point of Unix exit codes is to communicate enumerated errors to programmers without having them have to intercept stderr and parse unstructured output. But to spot this error, of "I literally don't know how to use execve", all you need to do is look for the nonzero exit code. I suspect that the person who kicked this subthread off didn't realize that the error can't be triggered from the shell (like, they thought it was "insufficient arguments" and not "malformed input to execve"), and now we're just bikeshedding a justification for being angry at Unix error codes. Seems like not a super valuable discussion to have. One good reason not to have a user-friendly error message here is that literally no user will ever see it. In fact: it's likely that in the entire history of this program, it has never once been executed in the fashion that would generate this error, except to exploit it.
    - noobermin 5y ago
      Again this is indeed a bike-shedding conversation but how hard is it to print an error message along with the error code? Seems harmless enough and just one more line of code.
      - tptacek 5y ago
        Should FreeBSD print a nice error message when it EFAULT's even the attempt to exec a program, any program, with argc==0?

tptacek 5y ago

The point of exit codes is that they're straightforward for programmers to extract, rather than error messages, which require the programmer to capture and parse stderr. So, no, I don't think you've rescued this very bad argument.

ajiknight 5y ago
I don't think this is a bad argument at all. It wouldn't kill anyone to include a brief stderr worthy message along with the exit. Especially when, and correct me if I'm wrong, code 126 is pretty vague here. "Command not executable" doesn't seem even correct to me.
- tptacek 5y ago
  The entire point of Unix exit codes is to communicate enumerated errors to programmers without having them have to intercept stderr and parse unstructured output. But to spot this error, of "I literally don't know how to use execve", all you need to do is look for the nonzero exit code. I suspect that the person who kicked this subthread off didn't realize that the error can't be triggered from the shell (like, they thought it was "insufficient arguments" and not "malformed input to execve"), and now we're just bikeshedding a justification for being angry at Unix error codes. Seems like not a super valuable discussion to have. One good reason not to have a user-friendly error message here is that literally no user will ever see it. In fact: it's likely that in the entire history of this program, it has never once been executed in the fashion that would generate this error, except to exploit it.
  - noobermin 5y ago
    Again this is indeed a bike-shedding conversation but how hard is it to print an error message along with the error code? Seems harmless enough and just one more line of code.
    - tptacek 5y ago
      Should FreeBSD print a nice error message when it EFAULT's even the attempt to exec a program, any program, with argc==0?