From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>, "'Andris Pavenis'" <pavenis AT lanet DOT lv>,
   "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Subject: Re: GCC option -ansi and libstdc++-v3
Date: Fri, 23 Nov 2001 01:18:28 +0100
Message-ID: <000001c173b4$6052a120$fdf8e0d5@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <4331-Wed21Nov2001201010+0200-eliz@is.elta.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> > gcc -ansi defines __STRICT_ANSI__ which hides prototypes for some
> > function needed by libstdc++-v3. Here are some examples one 
> > can find quickly:
> > 	lrand48()  (recent report today about compilation errors)
> > 	strtoll() and strtoull() are also used 
> > 	maybe some others
> > They are detected at configure time without specifying -ansi.
> > So option -ansi may screw compilation of C++ sources. The same
> > about defining __POSIX_SOURCE__
> 
> I don't see the problem: similar trouble happens if someone compiles
> with -ansi a C program which uses non-standard functions.  The only
> difference is that in C++ a missing prototype is an error, not a
> warning.

I guess it depends on where they're used.  If using -ansi breaks, say,
valarray (which is ANSI C++ IIRC) because one of the template functions
uses a non-ANSI function, that is a problem.  I guess the basic problem
is that with templates, the library implementation mixes with user
space instead of being hidden from it (with a C library, there's no
problem if an ANSI function calls a non-ANSI one internally, as that
fact is hidden away when the library is compiled).

The best way around this (probably) would be to conditionalize the
HAVE_FOO defines (which I presume are still in _g_config.h or some
such header).  IIRC that controls what features get used.  So if it
has

#ifndef STRICT_ANSI
#define HAVE_LRAND48
#endif

there shouldn't be a problem, as the template code will not use lrand48
with -ansi.
If the functions in question really aren't ANSI, then such a change
really belongs in the official sources.  If they are, it merely means
our own headers need updating.