Re: [lmi] Upgrading to gcc-4.9.2

[Vadim Zeitlin]

On Sun, 20 Dec 2015 15:25:24 +0000 Greg Chicares <address@hidden> wrote:

GC> >  The former one is quite different and potentially serious and occurs with
GC> > DLL-imported functions only, not the DLL-exported ones. What happens with
GC> > _get_output_format() is that it's declared as DLL-imported in the standard
GC> > header, meaning that it is defined in the standard library used as a DLL,
GC> > but then it's redefined in the program itself. I don't really understand
GC> > how this is even supposed to work and IMO a better idea than avoiding the
GC> > warning here would be to stop redefining this standard library function
GC> > entirely as I already wanted to do back in 2011:
GC> > 
GC> >   https://lists.gnu.org/archive/html/lmi/2011-06/msg00039.html
GC> 
GC> https://lists.gnu.org/archive/html/lmi/2011-06/msg00039.html
GC> | [...] apparently using this function is some sort
GC> | of a hack in the first place and that, quoting
GC> | http://article.gmane.org/gmane.comp.gnu.mingw.user/28747
GC> |
GC> |         adding PRINTF_EXPONENT_DIGITS=2 to your environment remains
GC> |         the preferred way to achieve this
GC> |
GC> |  So maybe we could do this instead?
GC> 
GC> That "preferred way" is just the personal preference of the mingw.org
GC> maintainer, who doesn't deploy MinGW-built applications into production.
GC> We do. We want the behavior that the standard requires, not the wrong
GC> default msvcrt.dll behavior; and we want to enforce that robustly.
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 

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

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.

 Regards,
VZ