Re: [lmi] Upgrading to gcc-4.9.2

[Greg Chicares]

On 2015-12-20 14:04, Vadim Zeitlin wrote:
> On Sat, 19 Dec 2015 20:32:14 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Here's the relevant part of 'database_document.hpp':
> GC> 
> GC>   #include "dbdict.hpp"
> GC> [...]
> GC>   class LMI_SO database_entity;
> GC> 
> GC> Header "dbdict.hpp" happens to include "dbvalue.hpp", which defines
> GC>   class LMI_SO database_entity
> GC> and g++4.9.2 complains when it sees a perfectly-matching forward
> GC> declaration after that definition.
> GC> 
> GC> I could remove the forward declaration--and it would compile, for now
> GC> at least. But I don't want to do that. It's not guaranteed to work
> GC> forever: I might make a change that makes the forward declaration
> GC> non-redundant, so removing it introduces a latent error.
> GC> 
> GC> Vadim, do the WXDLLIMPEXP_FWD macros work around this compiler anomaly?
> 
>  Yes, exactly. They expand to nothing when using gcc while expanding to the
> same thing as the FWD-less versions for the other compilers (MSVC,
> basically).

Okay, thanks, now I know how to handle this.

>  Notice that the problem solved by these FWD macros indicated by "type
> attributes ignored after type is already defined" warning is different from
> the original one with "previous dllimport ignored" warning, even if both
> warnings fall under -Wattributes. The latter warning, with the class
> redeclaration after its definition had been already seen, is harmless and
> it's enough to just not use the attributes in the forward declaration to
> get rid of it as using or not using them doesn't actually change anything.
> 
>  The former one is quite different and potentially serious and occurs with
> DLL-imported functions only, not the DLL-exported ones. What happens with
> _get_output_format() is that it's declared as DLL-imported in the standard
> header, meaning that it is defined in the standard library used as a DLL,
> but then it's redefined in the program itself. I don't really understand
> how this is even supposed to work and IMO a better idea than avoiding the
> warning here would be to stop redefining this standard library function
> entirely as I already wanted to do back in 2011:
> 
>       https://lists.gnu.org/archive/html/lmi/2011-06/msg00039.html

https://lists.gnu.org/archive/html/lmi/2011-06/msg00039.html
| [...] apparently using this function is some sort
| of a hack in the first place and that, quoting
| http://article.gmane.org/gmane.comp.gnu.mingw.user/28747
|
|         adding PRINTF_EXPONENT_DIGITS=2 to your environment remains
|         the preferred way to achieve this
|
|  So maybe we could do this instead?

That "preferred way" is just the personal preference of the mingw.org
maintainer, who doesn't deploy MinGW-built applications into production.
We do. We want the behavior that the standard requires, not the wrong
default msvcrt.dll behavior; and we want to enforce that robustly.
Letting the behavior depend on an environment variable is not robust.

What if an end user fails to set this variable, or sets it incorrectly?

What if end users are not allowed to set environment variables due to
corporate restrictions?

What if anti-malware software detects the environment change and takes
draconian action to "protect" our end user?

We don't have to think about those nasty consequences because we take
care of this inside lmi. AFAICS, that serves the end user best; and
if it forces us to write a pragma that we find distasteful, then it's
the least awful option.