This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New FreeBSD 5-current failures


In article <20030325135113 dot GA11696 at alinoe dot com>,
Carlo Wood<carlo at alinoe dot com> writes:

>> Comments, before I implement and test this approach?

Hi Carlo, thanks for the input.  It did cause me to rethink my
position.  In some cases, I strengthen my argument; whereas, in
others, I do agree with you.

> 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.

Agreed, but AFAIK this comment is directed at gcc's own behavior not a
system's libc or its headers.  If a library is shipped with gcc
(i.e. the situation under discussion), then it's behavior should match
the above quoted text.  If I'm wrong in this view, then I will happily
be corrected (and fixinc could be used to override the system header).

What about -posix?  That is actually a tougher nut to crack and is
probably affecting many other ports that support -posix and/or the
macro _POSIX_C_SOURCE to obtain levels of compliance; you just don't
always see it since the testsuite doesn't actually test for it AFAIK...

> 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 ['s system headers are] using
> __STRICT_ANSI__ in a way that was not intended, or the meaning as we
> see it should be reconsidered.

It is not my place to decide how FreeBSD system headers manage
standard compliance.  I am quite happy with the improvements they have
made in that regard.  Opinions vary on namespace pollution but I think
the general trend has been to tighten/remove name leakage.  By
default, FreeBSD exposes everything from every system header.  I think
both Solaris and Linux attempt the same but obviously vary in the
details.  In any event, it is symbols that are removed from the
namespace exported by system headers NOT gcc's support for 'long long'.

> 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.

Agreed, it is my intention to ensure that __FreeBSD__ (or other
per-port checks) need not appear in user C++ programs (esp. those
using the headers defined by the C++ standard).  Also, it has been my
intention to produce general changes to libstdc++-v3 when I support
FreeBSD rather than port-specific hacks.  At the moment, I note to you
that exactly one occurrence of eregexp _?_?[fF]ree[bB][sS][dD]_?_?
appears in all of libstdc++-v3 code.  It is in a threaded testcase and
it disappears once early versions of FreeBSD 4 disappear... ;-)

Thus, I completely agree with you here.

> A better way would be to either copy the way the FreeBSD people treat
> -ansi,

OK, this is actually the patch I proposed to write.  Perhaps, I didn't
explain in enough detail how it will affect no other ports unless they
have a similar problem and drop explicit support into their
os_defines.h file. ;-)

> 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.

Well, I documented once particular command line
parameter/option/user-provided macro that causes the problem.  There
are others.  The error message produced is not obvious as to what the
key problem is.

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

I'd tend to agree that this isn't much of an issue for real users once
they understand the error text.  However, I'd expect much cursing of
my name from the FreeBSD camp, if I didn't do something about this
before the 3.3 release.

It is an argument only in that it is masking visibility into real
failures in a primary testing platform.  One with a primary alternate
libc implementation to glibc (I would consider Solaris' libc another
primary alternate, in terms of divergence of original source of code
base).  As you know, it is very important that gcc changes be tested
against multiple libc since we claim to support what we find rather
than specific implementations.  If I have 100s of g++ failures due to
this error, then I can't spot and kill the remaining issues.

Regards,
Loren


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]