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 Sat, Sep 23, 2000 at 03:19:33PM +0200, Mark Kettenis wrote:
> The Austin draft clearly states that (2.3 Error Numbers):
> 
>   The value of errno should only be examined when it is indicated to
>   be valid by a function's return value.
> 
> I assume that this is equivalent to what the current POSIX standard
> says.
> 
> Since fcntl is not an ISO C function, its current behaviour is
> perfectly fine, and elm isn't a POSIX conforming application and
> should be fixed.
> 
> Somebody, preferably a native speaker, should probably clarify the
> glibc manual on this issue.
> 

See the code segment in

http://sources.redhat.com/ml/libc-hacker/2000-09/msg00148.html

It doesn't violate any standard if glibc doesn't change errno for
successful return as stated in the glibc manual. For the better
or worse, we just cannot change the documented glibc behavior unless
we have a really good reason. Otherwise, we can just delete the whole
glibc manual since it doesn't mean anything and the glibc behavior can
change at any time.

Please think what it meanes to the Linux application developers. At
least, we will lose any credibility we have in the glibc manual. We
cannot even tell them "read and follow the glibc manual." What does
it tell the world?

I'd like to remove all bunch of old compatibilty stuff in glibc. Why
cannot we do that? Rememeber for some projects, changing the source
for the glibc change may not be acceptable. They may not even have
the source code. Even if they do, it may not be changed so easily.


H.J.

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