[Top][All Lists]

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

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

From: Derek Robert Price
Subject: [Bug-gnulib] Re: CVS update [cvs1-11-x-branch]: /ccvs/src/
Date: Fri, 03 Sep 2004 10:48:28 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Hash: SHA1

Paul Eggert wrote:

> Derek Robert Price <address@hidden> writes:
>>a wrapper around the fwrite() function would prove as effective and
>>is almost certainly more efficient.
>More efficient, yes.  But 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.  fprintf is
the only one that might really be a pain, but I was thinking I could
leverage the GNULIB vasnprintf code for that.  I could probably even
do that in two lines (three counting the free) by vasnprintfing into a
string and fwrite_blocking the resulting string.

>only if you know all the locations that invoke fwrite.  Furthermore,

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

>surely you'll need to wrap fflush as well (you can't just call fclose
>or rely on the default close), and it's not immediately clear to me
>whether you can recover portably from an fflush EAGAIN failure.
>Furthermore, I'm worried about bugs in fwrite implementations in the
>presence of EAGAIN failures.

I can't speak on the likelihood of bugs in EAGAIN behavior.  Are they
common?  Larry Jones assured me that as long as I was writing single
bytes (as my example did), I should be able to rely on the EAGAIN
behavior of fwrite across platforms.  As for fflush, why shouldn't I
simply be able to select and call fflush again on EAGAIN?  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?

>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?  I tried to implement the POSIX specification or
fwrite conscientiously, with the addition of the guaranteed simulated
blocking behavior, though the code still remains uncompiled. You
should notice that I write the incoming data a byte at a time so that
I can (hopefully) rely on the EAGAIN behavior.  I also store the
complete number of objects written (based on the original object size)
so that on errors other than blocking errors the count of complete
objects written may be returned.

>If output is unbuffered, and if you use only 'fwrite', then perhaps
>it'd be simpler to use 'write' instead of 'fwrite'.  Or, if you're
>using fwrite only to get buffering, perhaps it'd be simpler to buffer
>things yourself and then use 'write'.

Maybe, though I liked the idea of the wrapper since it would be one
less piece of CVS specific code to learn for new developers.
Especially since the problem really does appear to me to be with the
way fwrite behaves.  Once the wrapper was installed then fwrite could
be relied upon once again.



- --

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]