[haiku-development] Re: POSIX error code
- From: "François Revol" <revol@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 19 May 2008 17:36:51 +0200 CEST
Comments:
> Not surprisingly, there are already applications out there that
> assume
> positive error codes, and those are hard to port to our otherwise
> POSIX
> compliant system.
They are not "hard" to port, I ported several of them.
It's just a time-consuming task to replace every "return -EFOO",
"return -errno", and "ret != -EFOO" to use a RETERR macro... and you're
never sure you didn't forget one.
Some software sometimes use them in such a nasty way it makes it much
harder though (thinking about libusb).
Usually the patch is not vetoed so it goes easily.
But it would be simpler of course if people would not write such
ugliness, and having standard not require but actually "require not to
assume positiveness" would help this.
See OSS patch:
http://revolf.free.fr/beos/patches/oss-v4.1test0-070827-beos.diff.001.txt
It is interesting to note that though this practice or return -EFOO has
been used for decades in Unix kernels (and there is no reason to forbid
it inside their own kernel code as long as it doesn't slip out of it,
but portable kernel code should however not make this assumption (like
OSS)), it is only recently that this behaviour has been seen in
userland code (ffmpeg, libusb, ...), at least in my own experience.
IMO using already negated error codes is actually less error-prone,
because one doesn't always have to check if they need to use -. Indeed,
sometimes APIs use "0 = OK, !=0 = error", and returning -EFOO makes
calling code miss EFOO errors... Sometimes also you add - when it's not
needed, or forget it where it is.
I recall having to fix one -EFOO in a userland app in OpenSound where
the minus wasn't needed...
But of course we won't change Linux, just like we wouldn't like us to
be forced to change.
> Is there any way this change can be reverted, or limited in a way
> that
> allows Haiku to be POSIX compliant without breaking compatibility
> with
> previous versions of BeOS?
My suggestion would be:
"Error code must be non-zero values.
Error codes should not be assumed to be positive, but can be assumed to
all have the same sign."
A proposed macro to return a negative error from a function would be:
#ifndef RETERR
#if EINVAL > 0
#define RETERR(e) (-(e))
#else
#define RETERR(e) (e)
#endif
#endif
(name could maybe be standardized somehow so we could provide it in
standard headers).
This allows to do:
return RETERR(EINVAL);
or
return RETERR(errno);
or
int err = foo();
if (err == RETERR(EINTR)) { ... }
François.
Other related posts:
