From: Jason Green <mail AT jgreen4 DOT fsnet DOT co DOT uk>
To: Laurynas Biveinis <lauras AT softhome DOT net>
Cc: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Subject: Re: Symify fixes
Date: Thu, 31 Aug 2000 23:45:28 +0100
Message-ID: <khmtqs4e3j50o3tup2r5rm7trbal670nrb@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> <3b5rqskv9adg5lcc3p4nhg2doib859r3n8 AT 4ax DOT com> <39AE0E92 DOT C8E0A73B AT softhome DOT net> <4k7tqskuugpt8r78ls4hnt2cfhuggjdtu3 AT 4ax DOT com> <39AEBA9E DOT A3E011AF AT softhome DOT net>
In-Reply-To: <39AEBA9E.A3E011AF@softhome.net>
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 SAA01065
Reply-To: djgpp-workers AT delorie DOT com

On Thu, 31 Aug 2000 22:05:50 +0200, you wrote:

> Jason Green wrote:
> > bail() will be called due to fseek outside file boundary, or fread
> > past eof; these are not failed system calls.  
> 
> Right, fseek() does not fail here. I don't know about fread.

AFAICT, fseek() only fails when seeking to before the start of file.

fread(), in effect, never fails.  It just returns less bytes than you
asked for ;-).  

The underlying cause could be a disk error, or just hitting eof.  The
idea is you call feof() and/or ferror() to find out what happened.  I
suspect if ferror() returns true then errno will have some meaningful
value.

> > If you know these
> > functions will always set errno=0 (no POSIX function is required to do
> > that) then your code would be safe.
> 
> To be more exact, these functions do not alter errno at all, if they succeed.
> But this is OK too, unless some previous system function has failed, and this
> failure wasn't handled properly.

That is the risk with this approach.

> > Perhaps you
> > could mail the patch first, I'll re-run the tests I did, then you can
> > commit it.
> 
> OK, I sent them in a separate mail.

I would change only one thing - for consistency:

--- src/debug/common/syms.c.bak	Thu Aug 31 23:18:50 2000
+++ src/debug/common/syms.c	Thu Aug 31 23:18:58 2000
@@ -569,7 +569,7 @@
   FILE *fd = fopen(fname, "rb");
   if (fd == 0)
   {
-    perror(fname);
+    bail(fname);
   }
   else
   {


With the previous patches I posted, posible error messages were:

SYMIFY ERROR: unexpected end of file
SYMIFY ERROR: error reading from file
a:/foo: Permission denied (EACCES)

Under same conditions, with your patch plus the one above:

Symify error: unexpected end of file
Symify error: error reading from file: Permission denied (EACCES)
Symify error: a:/foo: Permission denied (EACCES)

Under same conditions, unmodified symify would:

Give misleading results, crash, GPF, lock-up reading a: drive.

So I say - commit the modified bail() plus the above patch.
-- 
[please cc all replies, thanks]