Re: [lmi] MinGW-w64 binary standard streams

[Vadim Zeitlin]

On Mon, 22 Aug 2016 23:47:20 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-08-22 22:40, Vadim Zeitlin wrote:
GC> > On Mon, 22 Aug 2016 21:32:14 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> Here's the workaround I just added:
GC> > GC> 
GC> > GC> #if defined LMI_MSW
GC> > GC>     // Force standard output streams to binary mode.
GC> > GC>     setmode(fileno(stdout), O_BINARY);
GC> > GC>     setmode(fileno(stderr), O_BINARY);
GC> > GC> #endif // defined LMI_MSW
GC> > GC> 
GC> > GC> which does get rid of the CR-NL above.
GC> > 
GC> >  FWIW (and this is not much, seeing how there is no any other alternative
GC> > anyhow), I rather prefer this "workaround" to the original "solution"
GC> > because it's much more explicit and less magic.
GC> 
GC> Perhaps you regard CRNL as an OS convention,

 I do, but only because, objectively, this is what it is. You can try to
avoid using CR LF EOLs under MSW and you can even mostly succeed, but it's
still far too easy to encounter a file using them to just refuse to handle
them entirely.

 And producing only LFs on output is not ideal because this means the files
can't be opened in Notepad, which is, incredible as it may seem, still used
by many people to open text files.


GC> >  The only better solution I see would be to avoid doing this entirely and
GC> > update test_coding_rules_test.sh to deal with CRs in the input. I think
GC> > this would be the least surprising behaviour of all, under MSW.
GC> 
GC> My original, hasty, local workaround was:
GC> 
GC>    | sed -e '/^[ 0-9]\{9\} \(source files\|source lines\|marked 
defects\)/d' \
GC> +  | tr --delete '\r' \
GC>    >eraseme_observed
GC> 
GC> but from my POV that's a "band-aid" that leaves the real problem in place;
GC> and I wouldn't be surprised to find other, similar manifestations later.

 IMO this is a perfectly reasonable workaround which definitely doesn't
have any drawbacks, unlike the one currently used.

 Regards,
VZ