No further comment for a couple of years, so I'm closing this bug
report. Any remaining issues can be re-raised in a new report as needed.
On 02/16/2017 10:08 AM, Eli Zaretskii wrote:
I'm well aware that their needs are of a very low priority to you.
I would not say "very low priority". (To me, "very low priority" would
be something like supporting GNU grep on IRIX. :-) Regardless, it's
better not to try to personalize any disa
On 02/16/2017 09:26 AM, Eli Zaretskii wrote:
It seems to me that when one bumps into some code which looks
incorrect or less than optimal, and one considers its replacement with
a more clever code,
No, that's not it. The idea was to simplify maintenance for the GNU
case, perhaps at some cost t
> Cc: 25...@debbugs.gnu.org
> From: Paul Eggert
> Date: Thu, 16 Feb 2017 09:45:43 -0800
>
> On 02/16/2017 09:26 AM, Eli Zaretskii wrote:
> > It seems to me that when one bumps into some code which looks
> > incorrect or less than optimal, and one considers its replacement with
> > a more clever c
> Cc: egg...@cs.ucla.edu, 25...@debbugs.gnu.org
> From: Eric Blake
> Date: Thu, 16 Feb 2017 11:40:29 -0600
>
> On 02/16/2017 11:26 AM, Eli Zaretskii wrote:
>
> >> I'm of the opinion that undossify_input causes more problems than it
> >> solves. We should trust fopen("r") to do the right thing,
On 02/15/2017 06:23 AM, Eric Blake wrote:
xfreopen() may need a patch
Thanks for pointing out the problems with my suggestion. I think I'd
rather leave xfreopen alone, as silently adjusting its argument from
"wb" to "ab" might cause other problems. Instead, I added a Gnulib
module to set the
On 02/16/2017 11:26 AM, Eli Zaretskii wrote:
>> I'm of the opinion that undossify_input causes more problems than it
>> solves. We should trust fopen("r") to do the right thing, rather than
>> reinventing it ourselves.
>
> FYI: You'd be losing an important feature for non-Cygwin DOS/Windows
> us
> From: Eric Blake
> Date: Mon, 13 Feb 2017 14:20:56 -0600
>
> > While we're on the topic, the undossify_input approach is just a
> > heuristic and it sometimes guesses wrong. I wish the heuristic could be
> > removed somehow, so that grep would behave more deterministically on
> > MS-DOS/Windows
On 02/14/2017 05:08 PM, Paul Eggert wrote:
> On 02/13/2017 12:20 PM, Eric Blake wrote:
>> undossify_input causes more problems than it
>> solves. We should trust fopen("r") to do the right thing, rather than
>> reinventing it ourselves.
>
> Yes, that makes sense. Attached is a proposed patch to i
On 02/14/2017 05:08 PM, Paul Eggert wrote:
> On 02/13/2017 12:20 PM, Eric Blake wrote:
>> undossify_input causes more problems than it
>> solves. We should trust fopen("r") to do the right thing, rather than
>> reinventing it ourselves.
>
> Yes, that makes sense. Attached is a proposed patch to i
On 02/13/2017 12:20 PM, Eric Blake wrote:
undossify_input causes more problems than it
solves. We should trust fopen("r") to do the right thing, rather than
reinventing it ourselves.
Yes, that makes sense. Attached is a proposed patch to implement this.
It assumes the patch you already submit
On 02/13/2017 02:00 PM, Paul Eggert wrote:
> On 02/13/2017 11:23 AM, Eric Blake wrote:
>> the use of fopen("rt") actively
>> breaks assumptions on a binary mount by silently corrupting any
>> carriage returns that are supposed to be preserved.
>
> Surely it's more typical for trailing CRs to be ig
On 02/13/2017 11:23 AM, Eric Blake wrote:
the use of fopen("rt") actively
breaks assumptions on a binary mount by silently corrupting any
carriage returns that are supposed to be preserved.
Surely it's more typical for trailing CRs to be ignored rather than be
preserved, even on binary mounts.
Commit 5c92a54 made the mistaken assumption that using fopen("rt")
on platforms where O_TEXT is non-zero makes sense. However, POSIX
already requires fopen("r") to open a file in text mode, vs.
fopen("rb") when binary mode is wanted, and at least on Cygwin,
where it is possible to control whether
14 matches
Mail list logo
