Eric Blake wrote: > 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().
As far as I know, I don't know. :) The only thing I know for certain is that ``popen (cmd, "rb")'' fails on my box and I know that ``fopen (file, "rb")'' works. > Or maybe it is simpler to just rewrite sharutils to use: > > popen (cmd, O_BINARY ? "rb" : "r") > > rather than changing gnulib's popen module. It's your call. Personally, I favor having gnulib's popen clients be shown a consistent interface across all platforms. The EINVAL return presumes that the caller of popen() doesn't know what they are doing, instead of presuming that the call doesn't know which platform it is running on. I prefer tolerance. > 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. There I don't know if popen-safer is calling rpl_popen, or if it is directly calling the native popen(). I think it is the latter with GNU libc. As such, it would also need to protect the mode string. > 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. I'm not an autoconf guru. I leave it to your judgment on how to fix it. > 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. Sure. Thanks! Regards, Bruce
