Eric Blake wrote: > According to Eric Blake on 2/22/2010 4:29 PM: >> According to Bruce Korb on 2/22/2010 3:50 PM: >>>> The question, though, is whether cygwin's extension is useful enough to >>>> push on all platforms. Gnulib tends to favor glibc extensions rather than >>>> cygwin extensions. In other words, it is hard to justify replacing a >>>> glibc function that is perfectly standards-compliant. >>> >>> My philosophy is slightly different. I prefer to go with whatever it is >>> that makes life easier for programming to multiple platforms. >> >> http://sources.redhat.com/bugzilla/show_bug.cgi?id=11312 > > Unfortunately, Uli rejected it today. > >> We'll see if others agree with your argument, or whether it is just >> simpler to fix the caller. I'd prefer to wait for some feedback from the >> glibc folks before doing anything in gnulib. > > Given that Uli outright rejected the proposal of supporting popen(,"rb"), > does anyone else think it is worth changing gnulib to unilaterally declare > that glibc's popen is deficient (perhaps by adding a new module > popen-binary, so that those worried only about POSIX compliance don't have > to pick up on the bloat),
If there must be a module, I agree: POSIX-only popen users should not be impacted. > or is this a case where sharutils should just > get used to writing popen(,O_BINARY?"rb":"r")? However, this is so simple, I'd say it's not worth a module.
