Mail Archives: djgpp-workers/2000/08/30/20:08:08
On Wed, 30 Aug 2000 19:56:53 +0200, you wrote:
> > Maybe this function could be improved by adding perror() call
I did actually think about this. fseek() and fread() are not listed
(in the POSIX P.G.) as setting errno. To know that these functions
will set errno requires inside knowledge of libc, so I played it safe.
> > if errno != 0?
It's not sufficient to simply test errno to see if an error occured,
because it only has meaningful value if tested after a system call
that has returned some failure indication.
So, IMHO, it's not appropriate to use errno in this case. But I can
modify the code to do that if you wish.
> It's probably better to use strerror, since you already have an
> fprintf.
Yep, strerror with fprintf is the easiest way. There is some generic
code by Richard Stevens which takes printf style arguments to provide
better context to the error reporting, I can dig this out if you like.
> But I agree that a more specific error message is a good idea.
I don't see how it is possible to give more specific error messages,
unless you just mean change of wording, with this type of 'safety net'
code. Really what needs to happen is some proper sanity checking of
the values *before* attempting to index past EOF, read in huge
buffers, etc.
FWIW, the only message I solicited under testing was "SYMIFY ERROR:
unexpected end of file".
The patches don't attempt to fix the problem of reading in corrupted
COFF information (how often does this happen anyway?), just provide a
graceful exit after symify fails to detect the COFF info is corrupt,
or when something bad happens during the file access.
At the moment what happens is that symify will continue until, at some
point, things get bad enough for it to bomb with a stack dump or GPF.
--
[please cc all replies, thanks]
- Raw text -