From: Jason Green <mail AT jgreen4 DOT fsnet DOT co DOT uk>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc: lauras AT softhome DOT net, djgpp-workers AT delorie DOT com
Subject: Re: Symify fixes
Date: Thu, 31 Aug 2000 00:21:07 +0100
Message-ID: <3b5rqskv9adg5lcc3p4nhg2doib859r3n8@4ax.com>
References: <226lqssqgqp6i9nk82rvrqhl9aaia029e9 AT 4ax DOT com> <7458-Mon28Aug2000203504+0300-eliz AT is DOT elta DOT co DOT il> <ltflqs8ouggncaukmesirq7rsbsi4umrj5 AT 4ax DOT com> <8011-Mon28Aug2000234727+0300-eliz AT is DOT elta DOT co DOT il> <ttvnqs0p0rib0eja7eiijst64vbgp9tl1b AT 4ax DOT com> <39AD1BF3 DOT 139CB5DB AT softhome DOT net> <9003-Wed30Aug2000195653+0300-eliz AT is DOT elta DOT co DOT il>
In-Reply-To: <9003-Wed30Aug2000195653+0300-eliz@is.elta.co.il>
X-Mailer: Forte Agent 1.7/32.534
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id TAA28684
Reply-To: djgpp-workers AT delorie DOT com

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]