I can see the human factors perspective, but it boils down to ambiguity: "argument" can mean either the data supplied by the user, or the data supplied by the program to the kernel. That arises because (a) the particular error code, and (b) it's being written in English. That ambiguity won't necessarily exist in all languages (*1), and other languages may introduce ambiguities in other error messages that don't exist in the English versions.
In general a good error message should include 4 things: - Who detected the error (usually the name of a library function, or "the kernel"); - The error code reported by the code that detects the error condition, typically a library or the kernel; codes like EINVAL are OK, since they need to be translated anyway. - What was being attempted when the error occurred, including the parameters; “obtaining the extended attributes of source file ‘Foo’”. - How that connects to the user's actions. (Other information may be useful to the user, but is out of scope for this.) Fundamentally, errno exists to communicate from libc & the kernel to programs. It's a good hint about what you should pass up the chain, but it's clearly limited. Fixing the presentation of error messages, in a way that works across languages and across error codes is non-trivial, as it needs to work: - In all languages using separate translations for each of the 4 components - With a reasonably natural flow in each language (different languages use different word orders, and different ways of linking subordinate clauses) - For future error codes that don't exist when the code is written (strerror is in a shared library that can be updated without needing to rebuild client code). - Without having to write different code for different human languages. -Martin (*1: To be fair, it's likely an equivalent ambiguity would occur in many languages, especially European ones, but I would be surprised if this was considered ambiguous in *all* human languages.)
