[lmi] '-pedantic', '-std=c++98', and __STRICT_ANSI__

[Greg Chicares]

In private mail, Vadim had questioned the use of these flags.

A strictly-conforming program (in the C99 4/5 sense) can't use any
nonstandard library facility, so it can't be very useful in practice.
But that's not exactly what these flags enforce. The gcc manual says:

| Some users try to use -pedantic to check programs for strict ISO C
| conformance. They soon find that it does not do quite what they want

'-pedantic' is documented to mean
|  Issue all the warnings demanded by strict ISO C and ISO C++
C++98 never uses the word 'strict' in relation to conformance. In the
gcc manual, 'strict' really means standard requirements that the gcc
maintainers happen to dislike. I happen to disagree with them: in my
view, either one conforms to a standard or one does not. If there's
something '-pedantic' rejects that we really ought to allow, then
I'd like to hear about it.

'-std=' flags actually do two things. First, they enforce actual
rules of a particular dialect: for example, '-std=c89' rejects '//'
comments. That's the behavior I want (for C++, mostly, of course).
Second, they define the macro __STRICT_ANSI__; the gcc manual says

| Some header files may notice this macro and refrain from declaring
| certain functions or defining certain macros that the ISO standard
| doesn't call for; this is to avoid interfering with any programs
| that might use these names for other things.

I wish they'd separate those two purposes, because the second one
creates some needless problems. For instance, lmi uses snprintf(),
which is in C99 but not C++98. I don't think anyone would advocate
using sprintf() when snprintf() is available. Herb Sutter recommends
never using sprintf(), and always using snprintf() instead, in C++
programs, and he's the head of the C++ standards committee. MinGW
headers guard snprintf()'s prototype with '#ifndef __NO_ISOCEXT'
(which achieves the separation of purposes I desire), but apparently
gnu libc headers use __STRICT_ANSI__ instead.

When this __STRICT_ANSI__ problem arises, the desired headers should
be included in 'platform_dependent.hpp', which works around the
problems that macro causes.

Using these options (and the __STRICT_ANSI__ workaround) gives us
valuable extra diagnostics--for instance, to prevent accidental use
of gnu extensions to the standard language, which are generally bad
ideas IMO. Our goal is *not* to avoid use of nonstandard library
functions: it's to enforce use of the standard language. And these
flags are the only way to enforce certain language rules.

__STRICT_ANSI__ certainly doesn't prevent us from declaring a
function like wxFileNameFromPath(), so clearly it (and the flags
discussed here) don't attempt to restrict us to functions defined in
the standard library. According to the rationale quoted above, its
purpose is to permit
  long int memicmp(char* s, char* t, int n);
where the usual (but nonstandard) prototype is probably
  int memicmp(void const* s, void const* t, size_t n);
and that may have been useful before 1989 when C was standardized
(at least for poor programmers who used such functions incorrectly),
but now I think it's obsolete and merely harmful.