Re: CVS update [cvs1-11-x-branch]: /ccvs/src/

[Paul Eggert]

Derek Robert Price <derek@ximbiot.com> writes:

>>it's more effective only if you know that
>>only fwrite is used to deliver output (not fputc, fprintf, etc.), and
>
> Well, I was going to implement those functions as well.

Oh my goodness.  This reminds me of Emacs in the bad old days, when it
attempted to wrap the 'read', 'write', etc. system calls in order to
get BSD semantics after signals were received.  The wrappers were a
pain to maintain and required tweaking for new ports, or for new OS
revisions.  Eventually I persuaded RMS to drop them.

> No.  As I said, I would "#define fwrite fwrite_block", whether via
> config.h or another header which gets included everywhere.

config.h won't work if stdio.h #defines fwrite, which it's allowed to
do.  You have to include stdio.h first, then #undef fwrite, then
#define fwrite.  It can be done (Emacs did it, after all), but I don't
recommend it.

> I can't speak on the likelihood of bugs in EAGAIN behavior.  Are they
> common?

You're venturing into somewhat uncharted territory, so I'd expect
bugs, yes.  glibc had them (and may still, for all I know).  Other
platforms will be similar.

> As for fflush, why shouldn't I simply be able to select and call
> fflush again on EAGAIN?

As far as I can tell POSIX doesn't guarantee that repeated fflushes
will eventually write all the data, with no duplicates, in this
situation.  Here's the spec:
http://www.opengroup.org/onlinepubs/009695399/functions/fflush.html

> I notice that the C89 spec doesn't mention
> fflush setting errno (though the fflush in my version of glibc does
> appear to do this).  Is this what worries you?

POSIX says fflush sets errno.  I'm worried about implementations that
don't conform (or perhaps conform to an older standard?).  But I'm
also worried that there's no requirement that fflush remember the data
that wasn't output.

>>Also, I think your implementation will do the wrong thing if the
>>underlying fwrite writes out only part of a single object.
>
> What's wrong with it?

Perhaps I misread the code; sorry.  Certainly the "select" call needs
work, as there's not necessarily a blocking relationship between the
(buffered) stream and the (unbuffered) fd.