lmi
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]