Re: Some shadow fixes.

[Nathan Myers <ncm at cantrip dot org>]

On Fri, May 19, 2000 at 02:15:01AM -0700, Benjamin Kosnik wrote:
> 
> Nathan, can you summarize the state of this patch? It seems to me that all 
> the problem functions should just be declared "extern 'c'" and then they 
> are good for both std:: and ::
> 
> Right?

I don't think so.  We probably do need inlines, but not quite the 
way they were done in the patch.
 
> Can the  patch be revised to take this into account, and to deal with the 
> change from _C_Swamp -> _C_Legacy?
> 
> >Note, though, that the C++ standard doesn't include the C99 extensions,
> >so any such have to be guarded with #ifdef __USE_C9X.
> 
> This is an internal contradiction to the standard. It's clearly the 
> intention of C++ to be a superset of C, including C9X. 

Emphatically false.  ISO C++ is a mostly-superset of C89.
The committee explicitly did not try to track C9X (beyond
trying to encourage them to extend compatibly), and the C 
committee made no effort to remain compatible with C++ -- 
in some cases deliberately breaking compatibility,
apparently just for spite.  

Portable standard-conforming C++ code cannot depend 
on C9X features, and users need to be able to build in a 
standard-conforming and -enforcing environment.

> Let's deal with 
> the C9X issues the same way we deal with depricated code 
> (_GLIBCPP_DEPRICATED) or issues that have been resolved after the 
> standard was aproved (_GLIBCPP_RESOLVE_LIB_DEFECTS). 
> 
> Ie, in bits/c++config.h
> 
> # _GLIBCPP_USE_C9X 1

The commercial reality is that we are probably obliged to 
support a mixed C++ and C9X environment, but that doesn't 
mean we should make it harder than necessary to write 
portable code.  Sure, everybody's POSIX these days, but
we still demand _POSIX_SOURCE to get to it.

Nathan Myers
ncm at cantrip dot org