Re: [lmi] MinGW-w64 binary standard streams

[Vadim Zeitlin]

On Mon, 22 Aug 2016 21:32:14 +0000 Greg Chicares <address@hidden> wrote:

GC> This code, just removed from 'test_coding_rules.cpp', opened standard
GC> streams in binary mode before main() was called:
GC>     int _CRT_fmode = _O_BINARY;
GC> It worked with MinGW, but did nothing with MinGW-w64.
GC> 
GC> This message:
GC>   https://sourceforge.net/p/mingw-w64/discussion/723797/thread/2ee20d6e/
GC> suggests this workaround:
GC>     #undef _fmode
GC>     int _fmode = _O_BINARY;
GC> but that also doesn't work with MinGW-w64.
...
GC> In this thread:
GC>   https://sourceforge.net/p/mingw-w64/mailman/message/31444592/
GC> it is reported that linking 'binmode.o' also does not work; but the
GC> error report is dismissed.

 To be honest, this doesn't seem as egregious as other things I complained
about (such as shipping empty/do-nothing versions of C++11 threading
classes), but it's still a pretty bad silent compatibility breakage :-(

GC> As previously noted:
GC> 
GC> http://lists.nongnu.org/archive/html/lmi/2016-07/msg00037.html
GC> | For completeness, I'd also like to mention that the decision to not go
GC> | with TDM-GCC seems more and more regrettable retroactively

 But to be fair, in this particular case TDM-GCC behaves in the same way as
I've just tested using 5.1.0 x64 version. My guess (which I could check,
but I don't think it's really worth spending time on this) is that it's due
to using MinGW own (more) standard-compliant STDIO library instead of the
MSVC one which is used by default by all more or less modern MinGW versions
but wasn't used by the ancient 3.4.5.


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.

 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.

GC> It's not as robust as a built-in solution, because the streams might be
GC> used before main(),

 It would be a rather bad idea to output anything from global objects ctors
however, wouldn't it? I don't think lmi code does it anywhere. Another, and
potentially worse (IMHO) problem, would be that if we ever redirected
stdout or stderr somewhere by closing and reopening them, we could easily
forget to use setmode(O_BINARY). But this seems very unlikely in practice.

GC> I figure it does no harm to leave stdin in text mode.

 It's inconsistent and I think I'd rather use the same options for all the
standard streams, but I can't think of any place where lmi uses stdin at
all (except CGI code it seems?), so this is highly theoretical as well.

GC> I'm guessing it works with msvc too.

 Yes, initially I started replying to this message just to say that I've
tested this and it did, thanks,
VZ