Hi Michal,
> Hello,
"tl;dr -- is there any policy on error codes definition location and
value ranges?"
There is no written policy. But for myself, I have been thinking about
strategy how to deal with error codes for quite some time. I am considering
writing some guidelines in the Trac wiki, but not sure if others would share
my opinions.
> However, there are some situations when standard error
"codes are not sufficient for the domain. I guess only consistent
location is to put these codes to 'uspace/lib/c/include/errno.h' as
the return value codes are basically single global namespace and must
be "managed" centrally (since per domain custom codes could lead to
collisions). Hence my second question, is there any policy on error
codes value ranges?"
No, there is no policy no error code value ranges. The only way to manage
the single error value namespace is to put all the errno error codes in the
single errno.h.
So let's talk about what's in errno.h (in UN*X that is). Historically we've
got error codes used by C standard library APIs plus *some* (not all!) UN*X
APIs that thought they are important enough and need something different
from what's already there (notably BSD sockets).
Now I don't think adding randomly stuff to errno.h whenever I feel I have an
API that could make use of that is a good idea. I hate the idea of
monolithic errno.h with passion - it just doesn't scale and it actually
leads to bad programming practices rather than bringing any benefits,
really.
There are better, alternative approaches to returning errors. In my branch
https://code.launchpad.net/~jsvoboda/helenos/nettlapi I am actually removing
all networking-related errno codes with the plan to replace them with a
better alternative. I would like to suggest that in the future we actually
leave only these errno values in our naitve errno.h:
- those required by kernel (i.e. IPC-related)
- those required by the C standard (*possibly* also those required by VFS)
and I strongly suggest against introducing new ones.
We can discuss how to implement the alternatives if you'd like. Maybe we
could discuss this on HelenOS meeting or hangout (for more efficiency) and
then come up with some guidelines.
Cheers,
Jiri
"
Thank you,
Michal
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel";
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
