Re: [Libclc-developers] Re: libclc questions

[Hallvard B F. <h.b...@us...>]

Michael B.Allen writes:
>Hallvard B Furuseth <h.b...@us...> wrote:

You skipped one of the most important parts of my message:

   > But the standards do not say that malloc will not set errno to
   > ENOMEM and every malloc ever written _does_ use ENOMEM.

   Prove it.

You can't, right?  You can't even prove that _most_ mallocs ever written
do this.  Which means we won't dare depend on it.  Even if we believed
you are probably right, a 0.99% chance of being portable here and a
0.99% chance of being portable there quickly adds up to a 10% chance of
_not_ being portable.  Which is not good enough.  We are not building a
Library Which Will Probably Work For you.  We are building a Library
Which Will Work.  Period.

Incidentally, it took me all of 5 minutes of googling to find a malloc
library which does _not_ set errno like you say all mallcos do:
  http://www.mit.edu/afs/athena/contrib/watchmaker/src/malloclib/
So much for the "I'm sure everyone does this, since all code I've seen
does it" approach.

>>> Same goes for probably every other ISO function you'll use.
>>
>> fgetpos() can return ESPIPE (file descriptor is a pipe, FIFO, or socket)
>> on my system (Solaris).  Do you think that can happen on systems that do
>> not support pipes?
>
> Then they just won't return ESPIPE. I'm not sure I understand your
> point.

Well, then I sure don't understand yours, when you said
  "Same goes for probably every other ISO function you'll use."
_What_ goes for these functions?

> You can't squash the errno code.

Nobody is suggesting to do so.

>> So far, we don't know if we'll be using any CLC_E* error codes.  There
>> is little point in setting errno = CLC_ENOMEM in a function which can
>> only return one type of error, for example.  Then all the user needs it
>> to test whether or not an error happened.
>
> Well you should still set errno to be consistent. If a function returns
> an error and the practice has been to check errno you should set it even
> if there is only one possible errror code just to be consistent.

I don't know anyone who has the practice of checking errno when only one
error is possible.

(Or if you are talking about checking errno in order to find out if an
error happened at all, you have misunderstood errno badly and should
quit this discussion until you have read up on how it is used.  Errno is
*only* for saying which error happened when you already know that an
error did happen.  You should never check errno in order to find out
*if* an error happened - you test the function's return value to find
that out.)

>> The main point so far is that we want a standardized way which functions
>> can return error conditions if they want to.  We could have said that
>> such functions return an integer error code.  We chose not to; we
>> preferred to reuse the errno mechanism which already exists.  Given
>> that, we _had_ to open for the possibility that functions may need to
>> set errno to something which does not exist in any errno.h.
>
> The common E* identifiers are available with all significant libc
> systems.

Again, prove it.  And don't ignore that point this time.

> And if they are not there is likely a reason that you should
> not try to second guess. Even minimalistic non-POSIX system

A number of systems are smaller than Posix.  Or very different from
Posix, so an error with a name which also exists in POSIX errno.h might
exist but with another semantics.

> will have all the codes you would need for linked lists, configuration
> file modules and other such ANSI stuff.

So?  Tell me which E* code I'd use to report 'table is full', an error I
invented just now.  I couldn't find one on my Solaris box.

Not that it matters, though.  As I've already said, we are not building
a Library Which Will Probably Work For you.


> (...) Fortunately most implementations follow ISO C which
> permits errno to be a macro that evaluates to a modifiable lvalue. This
> is reentrant but it still doesn't provide a clean mechanism to communicate
> error codes within a multithreaded program.

What do you mean?  Errno on multithreaded systems typically expands to
an expression which refers to a thread-specific variable.  That seems
clean enough to me, if a little slow.

> There are two kernel programming idioms that you might also consider. I'm
> not advocating anything here I'm just providing you with options. The
> first is to always return the error code on the stack like:
>
>   if (getit(&ans)) == -1) {
>     return -ENOENT;
>   }
>
> If a pointer is normally returned you use ERR_PTR, PTR_ERR, and IS_ERR
> macros as described here:
>
>   http://www.win.tue.nl/~aeb/linux/lk/lk-2.html#ss2.7.3

Absolutely not.  Casting an integer to a pointer and back is _not_
portable, it might return anything.  It's OK for kernel code which is
already making assumptions about the compiler, but not for an ISO C
library.

> As long as we're on the topic of error codes I have another
> suggestion. Most library functions return -1 to indicate an error. For
> a while my personal library of stuff used 0 to indicate an error occured
> whereas 1 meant success. I recenty changed all of my functions to return
> -1 on error.

There was a thread about that on comp.lang.c a few days ago.  I think
the idea was that functions that can return several values on success
should return 0 on error, or -1/EOF if they can't return 0, but
functions that only return success/failure should return 0 or -1.

> Notices some multibyte string functions may also return
> -2 to indicate a different error although I don't know if any ISO C
> functions do this.

I don't think so, I think they use errno.

> I also feel it is important never to design an interface that provides
> no way to return an error indication.

Unless no errors can occur upon correct usage, I hope.  Like strcat.

> This can be easy to do when creating a function that returns a pointer
> to something but NULL is an appropriate value for the pointer
> (e.g. retrieving something from a table perhaps). But this leaves no
> way to indicate to the caller that an error occured.

The two suggestions being discussed on comp.lang.c now is to return a
struct with the "main" output value and an error code, and to return an
error indication and take an output argument in which to put the "main"
value.

> Finally, I know this is obvious but a library function should never set
> errno to 0.

Sure.

BTW, please read this article before making general suggestions:

   Subject: Re: libclc: error handling policy (wrapup)
   Newsgroups: comp.lang.c
   Date: Thu, 06 Mar 2003 20:34:51 GMT
   Message-ID: <LhO9a.14422$ZL2...@ju...>

-- 
Hallvard