This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: elm 2.5.3 and glibc 2.1.93


On Fri, Sep 22, 2000 at 01:52:32PM -0500, Mark Brown wrote:
> 
> 
> "H . J . Lu" wrote:
> >      Many library functions can set `errno' to a nonzero value as a
> >      result of calling other library functions which might fail.  You
> >      should assume that any library function might alter `errno' when
> >      the function returns an error.
> > 
> > From here, I conclude "The glibc functions do not change `errno' when
> > they succeed." By not saving/restoring errno, we have changed
> > documented glibc behavior. We should be consistent on it.
> 
> This doesn't follow. The text immediately above yours says that successful
> routines *can* change errno inadvertantly, and that you should not depend
> on errno *unless* the call reports failure.

This is straight from manual/texi:

---
The initial value of @code{errno} at program startup is zero.  Many
library functions are guaranteed to set it to certain nonzero values
when they encounter certain kinds of errors.  These error conditions are
listed for each function.  These functions do not change @code{errno}
when they succeed;
---

I have quoted it in my previous email. Did I read it wrong?

H.J.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]