Re: New FreeBSD 5-current failures

[Carlo Wood <carlo at alinoe dot com>]

> Anyone have an idea other than (a) multilib libstdc++-v3 X ways (I
> don't even see how to do that properly since X would be too large);
> (b) Add a _GLIBCPP_USE_C99_DYNAMIC_HOOK and
> _GLIBCPP_USE_LONG_LONG_DYNAMIC_HOOK macro that MAY BE defined in
> os_defines.h for a port and propagate its use to the ~13 libstdc++-v3
> headers that use one or both of the related macros.  It should be used
> solely to expose the namespace as the local system exposes libc.  The
> _GLIBCPP_USE_X_DYNAMIC_HOOK would be consulted only inside a region
> guarded by the related autoconf _GLIBCPP_USE_X macro.  For example, I
> think this is the os_defines.h implementation for FreeBSD 5.1:
> 
> #define _GLIBCPP_USE_C99_DYNAMIC_HOOK (__ISO_C_VISIBLE >= 1999)
> #define _GLIBCPP_USE_LONG_LONG_DYNAMIC_HOOK ((__ISO_C_VISIBLE >= 1999) && __LONG_LONG_SUPPORTED)
> 
> because it describes when the names will be available.  This seems the
> least kludgey and most likely to be useful in other contexts until we
> remove the dependency on the local libc (if that every happens).
> 
> Comments, before I implement and test this approach?

It seems to change the meaning of -ansi on this particular
platform.  From the manual of gcc:

  The -ansi option does not cause non-ISO programs to be rejected
  gratuitously.  For that, -pedantic is required in addition to
  -ansi.

The implementation of 'long long' does not collide with any ISO
definition that doesn't have 'long long' and therefore it support
is in principal not removed by the compiler when -ansi is used.

My conclusion is that FreeBSD is using __STRICT_ANSI__ in a way that
was not intended, or the meaning as we see it should be reconsidered.
Causing that macro (and thus the use of -ansi) to have different meanings
will introduce yet another portability issue (needing to use #ifdef __FreeBSD__
etc etc in every program that wants to be portable).  Of course that is
already needed anyway for all those different libc implementations, but
I'd hate to see it become needed for libstdc++ in itself too.

A better way would be to either copy the way the FreeBSD people treat
-ansi, or tell them they are mis-interpreting its meaning.

By NOT fixing this (but instead informing the FreeBSD maintainers)
nothing serious seems to be broken actually: it makes little sense
for a program that is 100% pure ISO C++ without extensions, except that
it uses 'long long', to use -ansi on the commandline; the 'workaround'
would be to remove that commandline parameter.

Finally, I think that purely a few testuite regressions shouldn't
be an argument.  We have to look at the background of their failure.

-- 
Carlo Wood <carlo at alinoe dot com>