Re: full_read depends on incoming errno

[Eli Zaretskii]

> Date: Tue, 19 Feb 2013 12:19:38 -0800
> From: Paul Eggert <address@hidden>
> CC: bug-gnulib <address@hidden>, Eli Zaretskii <address@hidden>
> 
> On 02/19/13 11:05, Andy Wingo wrote:
> > We use full_read in Guile and just got a bug report that full_read was
> > depending on the incoming errno.
> 
> Sorry, I don't see the bug here.  The calling
> code should look like this:
> 
>    size_t r = full_read (fd, buf, n);
>    if (r != n)
>      {
>         if (errno == 0)
>           handle_end_of_file ();
>         else
>           handle_error (errno);
>      }

It looks like this:

    if (full_read (fd, cookie, sizeof cookie) != sizeof cookie
        || full_read (fd, SCM_BYTEVECTOR_CONTENTS (bv),
                      SCM_BYTEVECTOR_LENGTH (bv)) != SCM_BYTEVECTOR_LENGTH (bv))
      {
        int errno_save = errno;
        (void) close (fd);
        errno = errno_save;
        SCM_SYSERROR;
      }

> Is this how Guile works?  If not, then it should probably
> be changed to work like that.  If so, then can you explain
> what the bug is, from Guile's point of view?

If the file is too short for these two reads, then errno will have
some random value (because full_read "succeeded" as far as that
function is concerned), and the error message in SCM_SYSERROR will
display something utterly unrelated to the real problem.

(The way I bumped into this was because fd was open in text, rather
than in binary, mode, and therefore the read ended up early due to
some ^Z byte in the byte stream.  But the diagnostics was misleading,
so I thought it was worthwhile to fix the diagnostics before fixing
the read mode.)

Btw, I don't think this is a gnulib problem, I think it's a Guile
problem, since from gnulib POV, nothing went wrong in that call.