Re: popen binary mode patch

[Eric Blake]

According to Bruce Korb on 2/22/2010 11:00 AM:
> This patch adds "binary mode" handling for popen() on platforms where
> the native popen() will not.  This is a problem especially on
> platforms where fopen() will ignore the 'b' but popen() will not.
> Hence, the test for "does fopen() accept a 'b'" won't apply to popen().
> GNU libc ought to just ignore the 'b', but it doesn't.

Thinking aloud here - do we even need a configure check?  Or would it just
be better to depend on the binary-io module, and use #if O_BINARY to
decide whether to strip 'b' before calling the real popen, and vs. letting
the underlying popen handle 'b'.  As far as I know, all systems with
non-zero O_BINARY support 'b' in popen().

Or maybe it is simpler to just rewrite sharutils to use:

popen (cmd, O_BINARY ? "rb" : "r")

rather than changing gnulib's popen module.

Why the change to popen-safer.c?  If we are replacing popen, then
popen_safer should get 'b' support for free by using rpl_popen.

The change to popen.m4 needs more work, if we do indeed decide to go with
a configure check.  It needs to use a cache variable, and provide sane
defaults for cross-compiling.

Should we file an enhancement bug report to glibc to add support for
ignoring 'b'?  It would be easier to justify this patch if we knew for
sure that glibc agrees with the concept of this extension.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature