Mail Archives: djgpp-workers/2000/09/02/13:25:37
On Fri, 01 Sep 2000 09:20:48 +0200, you wrote:
> > > The portable way to check for errno is to set it to zero before the
> > > call to a function, then see if it is still zero after the function
> > > returns.
> >
> > Actually no, a system call can legally set errno even if no error
> > occured.
>
> I think ANSI specifically disallows this: if no error occured, errno
> should be left alone.
You could be right, it's just that this is contrary to what I have
read elsewhere.
I'm interesting in getting a complete understanding of legal errno
usage, but that's not something to bore the list with. I've posted a
question about this to comp.lang.c and comp.unix.programmer which has
drawn some interesting (and conflicting) responses.
> In fact, the DJGPP library goes to great
> lengths to not set errno to bogus values, for example if you hit the
> end of directory during findnext.
For that reason, I think the modified bail() is ok.
> In any case, errno should be tested only if you have some other
> indication of a failure. But then `bail' is already called only under
> these circumstances.
Hmm, fread() hitting EOF does not set errno, and this is the error I
saw most commonly when testing with garbage program files.
Neither fread() nor fseek() are listed in the POSIX Programmers Guide
as setting errno. The system calls they make may well fail and set
errno, but we cannot tell this by simply looking at the return values.
From what I have seen, the *only* case here where bail() is called
with errno indicating a failure is when fread() returns less than the
required number of bytes *and* ferror() returns true.
The real point is whether to commit all or some of the patches to
symify. IMHO, modified bail() should be commited.
- Raw text -