Re: CVS update [cvs1-11-x-branch]: /ccvs/src/
Derek Robert Price <[email protected]> Fri, 03 Sep 2004 10:48:28 -0400
| Newsgroups | gmane.comp.lib.gnulib.bugs,gmane.comp.version-control.cvs.bugs |
|---|---|
| Organization | Ximbiot <http://ximbiot.com> |
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Eggert wrote: > Derek Robert Price <[email protected]> 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. Cheers, Derek - -- *8^) Email: [email protected] Get CVS support at <http://ximbiot.com>! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBOIQ7LD1OTBfyMaQRAu5jAKDqpUAHVEBLZ1flp6Hby+Kw20jEDwCg4Zhb HgKy8zUUU3gfVzRqS8CvPgA= =WZ2o -----END PGP SIGNATURE-----