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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
