Re: [PATCH] upload-pack: use buffered I/O to talk to rev-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 3, 2020 at 7:00 AM René Scharfe <l.s.r@xxxxxx> wrote:
>
> Am 02.08.20 um 18:03 schrieb Chris Torek:
> > The fclose() call doesn't necessarily check ferror().  (The
> > FreeBSD stdio in particular definitely does not.)
>
> Thanks, didn't know that.  That's awful.  So the sentence "The fclose()
> and fdclose() functions may also fail and set errno for any of the
> errors specified for fflush(3)." from the FreeBSD manpage for fclose(3)
> actually means that while it will flush, it is free to ignore any
> flush errors?
>
> Or do you mean that fflush() can succeed on a stream that has its error
> indicator set?

The latter.  You have to get particularly (un?)lucky here: say the
buffer size is n, and the *last* write operation (fprintf, whatever)
filled the buffer mod n and called fflush internally and that failed.
Then at the time you call fclose() the buffer is empty.  There is
nothing to flush, so we just get the result of the system's close()
call.

> In any case, we'd then better add a function that flushes the buffer,
> closes the stream and reports errors in its return code and errno --
> i.e. a sane fclose().

Unfortunately the global-variable nature of errno means it may be
clobbered by the time you inspect it here, again with the same sort
of issue above.  It might be nice if C's error conventions were more
like Go's, and stdio retained an earlier error, but this stuff all dates
back to 16-bit "int" and 512-byte buffers and no room for nice stuff. :-)

Chris




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux