Re: [lmi] Upgrading to gcc-4.9.2

[Vadim Zeitlin]

On Sun, 20 Dec 2015 16:33:38 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2015-12-20 15:39, Vadim Zeitlin wrote:
GC> > On Sun, 20 Dec 2015 15:25:24 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> Letting the behavior depend on an environment variable is not robust.
GC> > 
GC> >  Sorry, I should have linked my last reply in that thread as well, please
GC> > see the last paragraph of
GC> > 
GC> >   https://lists.gnu.org/archive/html/lmi/2011-06/msg00042.html
GC> |
GC> | [...] call putenv("PRINTF_EXPONENT_DIGITS=2") on program startup 
ourselves.
GC> 
GC> > I don't think setting the environment variable is less robust (if it works
GC> > at all, I admit I haven't tested it).
GC> 
GC> What if putenv() is forbidden by some present or future anti-malware 
program?

 Sorry, this doesn't seem reasonable. putenv() only affects the process
environment block which is inside the process address space itself, it's
not a syscall which could be hooked and forbidden. If you can't rely on the
process being able to write in its own memory, then you can't realistically
hope to be able to do anything at all.

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

 The workaround is trivial as this function was removed because MSVS 2015
behaves in a standard-conforming way by default and so it's not necessary
to call it any more. But for the earlier versions, it would actually fix
the behaviour of the program compiled with MSVC to match that of MinGW as
currently _get_output_format() is not used at all for it and if it were
used it wouldn't work anyhow because this function is supposed to be
called, not defined, by the application.

GC> ...but then I saw this:
GC> 
GC>   http://forums.thedailywtf.com/forums/p/19786/232680.aspx

 Sorry, I don't understand the problem here. It makes more sense to me for
this to be a global setting, would you really like different threads to
produce different outputs from printf()? And lmi code already relies on
this anyhow (or would rely if it used threads). If you call
_set_output_format() once on program startup -- as it should be done -- I
don't see anything wrong with it.

GC> The benefit is aesthetic only

 This is what I don't understand. For me the benefit is that you replace
some code which, IMHO, works only entirely by accident, by something that
is simpler, doesn't provoke any warnings and actually makes sense. I don't
care much about this either way, but it just seems very surprising that you
don't seem to see anything wrong with the continued presence of this voodoo
incantation in lmi code.

 Just one last question: do you actually understand how does redefining
_get_output_format() work? Because I freely admit that I don't and it feels
me uncomfortable to rely on something that I don't understand. And until
reading the above, I would have been ready to swear that this would be the
case for you too...

 Regards,
VZ