Re: [lmi] Upgrading to gcc-4.9.2

[Greg Chicares]

On 2015-12-20 15:39, Vadim Zeitlin wrote:
> On Sun, 20 Dec 2015 15:25:24 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> Letting the behavior depend on an environment variable is not robust.
> 
>  Sorry, I should have linked my last reply in that thread as well, please
> see the last paragraph of
> 
>       https://lists.gnu.org/archive/html/lmi/2011-06/msg00042.html
|
| [...] call putenv("PRINTF_EXPONENT_DIGITS=2") on program startup ourselves.

> I don't think setting the environment variable is less robust (if it works
> at all, I admit I haven't tested it).

What if putenv() is forbidden by some present or future anti-malware program?
Then we'd have to revert to what we have now, which is known to work. But then
what's the purpose of this experiment?

BTW, MinGW-w64 received a defect report that said repeated getenv() calls in
this library (which they've apparently adopted from mingw.org) are too slow.
They responded by caching the variable. Given that mingw.org seems never to
have noticed that problem, I have to wonder how well this path through the
library code has been tested.

> GC> if it forces us to write a pragma that we find distasteful, then it's
> GC> the least awful option.
> 
>  Actually I think the most straightforward and hardly-awful-at-all option
> would be to just call _set_output_format() instead of redefining
> _get_output_format(). As I wrote, I really have no idea how does the latter
> manage to work at all, it can only do it if all the code using it is inline
> in the headers and if it always binds to the function in the main program
> instead of the one in the CRT DLL. Clearly, it must work if you're using
> it, but this seems very fragile to me and I wouldn't be surprised at all if
> it stopped working with a next version of MinGW.
> 
>  So actually anything not involving the dirty hack with replacing the CRT
> function would IMO be more robust, not less.

I started writing this...

  I'd entertain a patch that calls this "set" function once and only once,
  at startup (in 'main_common.cpp' and in 'cpp_main.cpp', I guess), and
  works with both mingw.org and MinGW-w64 toolchains. You might need a
  workaround for msvc because they no longer provide this function:
    https://code.google.com/p/chromium/issues/detail?id=491979

...but then I saw this:

  http://forums.thedailywtf.com/forums/p/19786/232680.aspx

Wow. Maybe that's the reason why mingw.org's suggestion to replace
_get_output_format() actually works. Maybe they knew that, or maybe
they just stumbled into it by happy accident, but either way we don't
dare touch this. The benefit is aesthetic only; the risk is greater
than we had heretofore imagined, and I'm not taking lmi into
DailyWTF territory.