On Mon, Sep 25, 2017 at 05:13:54PM -0700, Jonathan Nieder wrote:
> > I actually prefer "0" of the all of the options discussed. At least it
> > is immediately clear that it is not a syscall error.
>
> I have a basic aversion to ": Success" in error messages. Whenever I
> see such an error message, I stop trusting the program that produced it
> not to be seriously buggy. Maybe I'm the only one?
That's a fair criticism, I think.
> If no actual errno works, we could make a custom strerror-like function
> with our own custom errors (making them negative to avoid clashing with
> standard errno values), but this feels like overkill.
Yes, I also thought about that. It feels pretty invasive (I guess we'd
wrap strerror() with our own custom function so that callers don't have
to remember which one to use).
> In the same spirit of misleadingly confusing too-long and too-short,
> there is also ERANGE ("Result too large"), which doesn't work here.
> There's also EPROTO "Protocol error", but that's about protocols, not
> file formats. More vague and therefor maybe more applicable is EBADMSG
> "Bad message". There's also ENOMSG "No message of the desired type".
>
> If the goal is to support debugging, an error like EPIPE "Broken pipe"
> or ESPIPE "Invalid seek" would be likely to lead me in the right
> direction (wrong file size), even though it is misleading about how
> the error surfaced.
>
> We could also avoid trying to be cute and use something generic like
> EIO "Input/output error".
I definitely would prefer to avoid EIO, or anything that an actual
read() might return.
What do you think of ENODATA? The glibc text for it is pretty
appropriate. If it's not available everywhere, we'd have to fallback to
something else (EIO? 0?). I don't know how esoteric it is. The likely
candidate to be lacking it is Windows.
-Peff
