From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Cc: <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 09:42:24 +0100
Message-ID: <000501c173fa$c6353ac0$158ce0d5@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: <2593-Fri23Nov2001100415+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

> > From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
> > Date: Fri, 23 Nov 2001 01:18:28 +0100
> > 
> > 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.
> 
> Is this really the case?

Yes. A quick shows that bits/stl_algo.h has

// Return a random number in the range [0, __n).  This function
encapsulates
// whether we're using rand (part of the standard C library) or lrand48
// (not standard, but a much better choice whenever it's available).
template <class _Distance>
inline _Distance __random_number(_Distance __n) {
#ifdef _GLIBCPP_HAVE_DRAND48
  return lrand48() % __n;
#else
  return rand() % __n;
#endif
}

> How can ANSI C++ do that without polluting the namespace?

It can't.  They made the mistake to think that 'detect once, use always'
is valid in C++.  Either this should be changed to check both
_GLIBCPP_HAVE_DRAND48 and !__STRICT_ANSI__, or we need to conditionally
add a define for _STL_NO_DRAND48 to bits/stl_config.h.

> Anyway, if that's the problem, we should solve it like we do with all
> non-ANSI functions that are required by ANSI functions: rename the
> real function to have two leading underscores, and make a stub for the
> old name.  Then #define the old name somewhere (in _G_config.h?) so
> that C++ headers are happy.

Not sure if that is wise - as far as we're concerned, libstdc++-v3 is a
user-space thing, so I think we should fix libstdc++-v3 instead of
providing workarounds for it.  Besides, it's only fair that if the user
asks for -ansi, she actually gets only ANSI functions where possible.
Since in this case at least the library can handle both cases, I think
we should let it.
Now if libstdc++-v3 also uses some non-ANSI function without an
alternative, THEN I'd consider adding a stub for that.