> Date: Tue, 19 Feb 2013 12:19:38 -0800
> From: Paul Eggert <egg...@cs.ucla.edu>
> CC: bug-gnulib <bug-gnulib@gnu.org>, Eli Zaretskii <e...@gnu.org>
>
> 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.
