[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: popen binary mode patch
From: |
Jim Meyering |
Subject: |
Re: popen binary mode patch |
Date: |
Mon, 05 Apr 2010 22:05:52 +0200 |
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.