[haiku-development] Re: Of errno signedness and standards
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 20 Jan 2009 18:21:13 +0100
On 2009-01-20 at 06:45:48 [+0100], François Revol <revol@xxxxxxx> wrote:
[...]
> > > What I have read from the available drafts seemed confuse enough to
> > > give me a headache. And we aren't changing our errors any time soon
> > > anyway.
> >
> > I'd actually vote for making the POSIX error codes standard compliant
> > as soon as
> > we have a chance. That is when we break binary compatibility. I would
> > keep the Be
> > API error codes negative, but change them to small absolute values,
> > so that
> > B_FOO_BAR == -EFOOBAR. This allows us to continue using the Be API as
> > we're used
> > to. Care must be taken when mixing Be and POSIX API though. I'd
> > introduce two
> > macros, B_TO_POSIX_ERROR() and B_TO_HAIKU_ERROR(), to convert the
> > error codes
> > where necessary. Our complete code base would have to be adjusted,
> > which should
> > be quite a bit of work, but compared to the overhead of forever
> > "fixing" ported
> > code -- and we all know this code will keep coming -- it will be more
> > than
> > worthwhile. We could even introduce and use the macros already; they
> > would just
> > be identity functions for the time being.
>
> This seems quite ugly though...
I find it rather clean actually. Code using either POSIX API or Be API
exclusively doesn't need to be changed at all. Only when mixing the two
error codes have to be converted. And I guess that doesn't even happen that
often. E.g. libtracker seems to use errno in exactly one place, src/apps/
and src/preferences/ together have about 40 occurrences.
> I suppose we have some time ahead to think about it, or buy ANSI
> people.
Well, this issue isn't new and we already had quite a bit of time to think
about it. Assuming the bribery^H^H^H^H^H^H^Hlobbying idea doesn't work out,
there are exactly two options: (1) Stick to the status quo and keep having
fun with ports or (2) change the POSIX error values. In case of (2)
changing all error values would also require massive changes to the API or
at least to negate error codes everywhere. Only making the POSIX error
codes positive, as proposed, is a way less intrusive solution. Better
alternatives are welcome, of course.
BTW, instead of just removing the negation of error codes in ported code,
I'd suggest to introduce a macro (e.g. B_TO_NEGATIVE_ERROR()) and use that.
So that we'll have less problems later, if we decide to change the sign of
our error values.
CU, Ingo
Other related posts:
