[haiku-development] Re: POSIX error code
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 21 May 2008 16:44:44 +0200
On 2008-05-21 at 17:43:38 [+0200], kaoutsis <kaoutsis@xxxxxx> wrote:
> Ingo Weinhold wrote:
> > On 2008-05-21 at 01:05:51 [+0200], kaoutsis <kaoutsis@xxxxxx> wrote:
> >> Ingo Weinhold wrote:
> >>> wrote:
> >>> Anyway, it certainly doesn't harm to try, but I have little hope that
> >>> this
> >>> will have any effect. If the standard maintainers consider the request,
> >>> they are in a dilemma. Undoing the Issue 6 error codes change means that
> >>> all the applications that relied on it would become non-conforming.
> >>>
> >> I agree.
> >> I had an idea how to tackle the problem, may be good, may be bad:
> >
> > The main problem is not binary compatibility. The problem is that the Be
> > API
> > requires that error codes be negative. E.g. create_sem() returns a
> > non-negative value (the sem_id) when successful, a negative error code
> > otherwise. A good deal of other functions/methods use the same strategy,
> > and
> > so does third party code. Making our error codes positive will break them
> > all.
> >
> > Changing concerned API functions to return -1 and set errno would be an
> > option, but that would be quite a bit of work and third party software
> > would
> > have to be changed as well. Personally I don't even find this option very
> > appealing.
> >
> >
> Also, i didn't find this idea very appealing and that was the 'easy part';
> i forgot the 'hard part' :-), just for the record here it is:
> all the functions that returns semIds, areaIds etc, they would
> check for errors like this:
> area_id areaSpaceId;
> areaSpaceId = create_area("AreaSpace",...
>
> if (areaSpaceId < B_OK) {
>
> problems:
> a) In all similar current code places, the 0 should be replaced with B_OK
> b) There must be an assurance that
> the valid ids should not conflict with the error codes.
If you really define B_OK to LONG_MAX, the number of valid IDs is *very*
limited. :-)
Even, if you pick a smaller number, a non-null B_OK doesn't sound like that
good an idea. The "no error" error code has traditionally been 0. By changing
that all code relying on it will break -- the checks you mentioned above, but
also the "status_t error = ...; if (error) {...}" kinds of checks, and we
would need to translate the error codes for the newer POSIX APIs that
directly return an error code.
CU, Ingo
Other related posts:
