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 <20030326002455 dot GA16787 at alinoe dot com>,
Carlo Wood<carlo at alinoe dot com> writes:

> I don't know, I never used -posix.  I suppose it causes _POSIX_C_SOURCE
> to be defined?

Yes, almost exactly as you supposed.  This appears to be supported on
an ad hoc, per-port basis in gcc.  The only thing that appears similar
across the board is setting _POSIX_SOURCE to 1 when -posix is
supported otherwise a warning is reported.  System headers take it and
diverge from that point (I can only guess that they all do something
reasonable w.r.t. POSIX specification at that point --- but, for
example, I see little commonality between Linux and FreeBSD in the
details of the default with and without that switch).  BTW, having
volunteered to rationalize switches used for threading across ports, I
will not reenlist (some improvement were made but by-in-large it is
still somewhat ad hoc)...

> I meant that when -ansi (and -posix) have the same meaning for every
> platform, then (continuing to use -ansi/__STRICT_ANSI__/long long as
> example) 'long long' must be fully supported, or not supported at all,
> by libstdc++ (and the compiler) equally on every platform as function
> of the commandline parameters only.

I am afraid the above could never be true.  For one thing, see my
comment above.  For another, the ABI of the library itself may be
configured to support or not support long long independent of native
gcc support for the type.  One portable strategy: the user code may
use a library-provided macro to decide how to map types.

> Maybe I read your mail not carefully enough as I understood that the
> use of '..._SUPPORT_LONG_LONG_HOOK' implied that the support of
> 'long long' by libstdc++ would be a function of the platform too.
> As a result, certain programs, using the same commandline
> parameters, would not compile on freebsd while they would compile
> for example on linux.

Well, you have to pick your battles I suppose.  At the moment, the
following C++ program doesn't behave the same on FreeBSD 5-CURRENT as
Linux under a selection of command line arguments:

#include <cstdlib>
int main(){}

To make matters worse, it outright fails to compile.  I think we
should guarantee compilation when a standard says we should (if
possible).  I think we should guarantee behavior within limits of a
standard where it says what we may do.  Making every port behave the
exact same in all cases, is another whole level.  Some languages have
attempted this (e.g. Java) but C++ doesn't.

Regards,
Loren


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