On 01/04/2013 09:36 AM, Paul Eggert wrote: > Instead of putting back that comment about the bug, > how about fixing the bug? Something like the following. > > Or perhaps a fix should be put into stdio.in.h so that > all gnulib programs can assume glibc behavior here, > for fwrite? Though this would mean using an extern > function, something that caused trouble with libvirt...
Having an extern (not inline) replacement rpl_fwrite for platforms that
can fail with ENOMEM seems reasonable, just like we have replacements
for any other function where we want to guarantee glibc semantics. That
just means adding a fwrite module and coming up with an appropriate .m4
file to determine when to compile the replacement fwrite.c. Do we even
know of platforms where fwrite will fail on ENOMEM without setting the
error indicator?
> +static void
> +fwrite_asis (FILE *fp, const CHAR_T *src, size_t len)
> +{
> + /* POSIX and ISO C allow fwrite to fail due to ENOMEM *without*
> + setting the stream's error indicator. Work around the problem
> + by invoking fwrite only on platforms we know are safe. */
> +#ifdef __GLIBC__
> + fwrite (src, len, 1, fp);
> +#else
> + while (len-- > 0)
> + {
> + fputc (*src, fp);
> + ++src;
This feels slow; wouldn't it better to still just call fwrite(), but
check for an error return, and if so, use the fseterr module to
guarantee that the stream error indicator is set?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
