[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] MinGW-w64 binary standard streams
From: |
Greg Chicares |
Subject: |
Re: [lmi] MinGW-w64 binary standard streams |
Date: |
Mon, 22 Aug 2016 23:47:20 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 |
On 2016-08-22 22:40, Vadim Zeitlin wrote:
> On Mon, 22 Aug 2016 21:32:14 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> Here's the workaround I just added:
> GC>
> GC> #if defined LMI_MSW
> GC> // Force standard output streams to binary mode.
> GC> setmode(fileno(stdout), O_BINARY);
> GC> setmode(fileno(stderr), O_BINARY);
> GC> #endif // defined LMI_MSW
> GC>
> GC> which does get rid of the CR-NL above.
>
> FWIW (and this is not much, seeing how there is no any other alternative
> anyhow), I rather prefer this "workaround" to the original "solution"
> because it's much more explicit and less magic.
Perhaps you regard CRNL as an OS convention, for which we substitute above
a different convention; whereas I view it as insane breakage, which calls
for a bulletproof fix in the RTL--so a toolchain-specific fix makes sense
to me.
> The only better solution I see would be to avoid doing this entirely and
> update test_coding_rules_test.sh to deal with CRs in the input. I think
> this would be the least surprising behaviour of all, under MSW.
My original, hasty, local workaround was:
| sed -e '/^[ 0-9]\{9\} \(source files\|source lines\|marked defects\)/d' \
+ | tr --delete '\r' \
>eraseme_observed
but from my POV that's a "band-aid" that leaves the real problem in place;
and I wouldn't be surprised to find other, similar manifestations later.