* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
@ 2005-10-03 3:42 ` neroden at gcc dot gnu dot org
2006-02-07 12:41 ` pinskia at gcc dot gnu dot org
` (13 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: neroden at gcc dot gnu dot org @ 2005-10-03 3:42 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from neroden at gcc dot gnu dot org 2005-10-03 03:42 -------
So there's a problem with the multiple-include-protection in glibc!
We actually want to include the headers twice, potentially -- once when
included via <cstdio> et al, with everything in namespaces, and once when
included directly via <stdio.h> et al, with everything outside them. They
actually shouldn't conflict because that's the whole *point* of putting stuff
in a namespace.
But we can't do this in any manner because they have multiple-include
protection which can't tell the difference.
I think this should be solved in glibc. Feel free to forward this suggestion
and this code (which I donate to the public domain) to somewhere appropriate.
At the beginning of stdio.h, instead of:
#ifndef _STDIO_H
#define _STDIO_H
we would have:
#if ( ( defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES ) \
&& ! defined _STDIO_H_WITH_NAMESPACES ) \
|| ( (! defined __cplusplus || ! defined _GLIBCPP_USE_NAMESPACES )\
&& ! defined _STDIO_H )
#if defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES
# define _STDIO_H_WITH_NAMESPACES
#else
# define _STDIO_H
#endif
For glibc, _GLIPCPP_USE_NAMESPACES could be defined in <cstdio> before the
inclusion of stdio.h and undefined afterwards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
2005-10-03 3:42 ` [Bug libstdc++/6257] C-library symbols enter global namespace neroden at gcc dot gnu dot org
@ 2006-02-07 12:41 ` pinskia at gcc dot gnu dot org
2006-04-18 15:10 ` marc dot glisse at normalesup dot org
` (12 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-02-07 12:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from pinskia at gcc dot gnu dot org 2006-02-07 12:41 -------
*** Bug 26153 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
2005-10-03 3:42 ` [Bug libstdc++/6257] C-library symbols enter global namespace neroden at gcc dot gnu dot org
2006-02-07 12:41 ` pinskia at gcc dot gnu dot org
@ 2006-04-18 15:10 ` marc dot glisse at normalesup dot org
2006-04-18 17:49 ` pcarlini at suse dot de
` (11 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: marc dot glisse at normalesup dot org @ 2006-04-18 15:10 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from marc dot glisse at normalesup dot org 2006-04-18 15:10 -------
(In reply to comment #15)
> So there's a problem with the multiple-include-protection in glibc!
Yes, the way it is done in solaris is way more convenient. There, stdlib.h
includes a file iso/stdlib_iso.h that has all the meat, and then stdlib.h does
all the using std::foo; stuff, so cstdlib can just include iso/stdlib_iso.h
directly. On solaris, I get quite satisfactory results with:
g++ -I/opt/SUNWspro/prod/include/CC/std -D__cplusplus=199711L -U__EXTENSIONS__
-D__STDC__=0
(the include directory contains the cstd headers from sunpro, but they are just
one or 2 #include lines)
> But we can't do this in any manner because they have multiple-include
> protection which can't tell the difference.
gcc could come with its own stdlib.h. Both this stdlib.h and cstdlib would
include /usr/include/stdlib.h (always with _GLIBCPP_USE_NAMESPACES) and the gcc
provided stdlib.h would additionally contain the appropriate using std::foo;
lines. The 2 problems I see with this approach are:
1) it means having 2 files with the same name in the search path, and inclusion
of the glibc file has to be done with an explicit path of /usr/include (or some
other compile time constant)
2) This will do what we want for standard functions, but what about extensions
that are declared in stdlib.h in glibc (protected by __USE_ISOC99 or __USE_GNU
for example), what happens to them? It might work well, I have not tested.
> At the beginning of stdio.h, instead of:
> #ifndef _STDIO_H
> #define _STDIO_H
> we would have:
> #if ( ( defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES ) \
> && ! defined _STDIO_H_WITH_NAMESPACES ) \
> || ( (! defined __cplusplus || ! defined _GLIBCPP_USE_NAMESPACES )\
> && ! defined _STDIO_H )
> #if defined __cplusplus && defined _GLIBCPP_USE_NAMESPACES
> # define _STDIO_H_WITH_NAMESPACES
> #else
> # define _STDIO_H
> #endif
This way you get 2 declarations instead of one and a using directive, I am not
sure it won't cause problems (but I don't know).
--
marc dot glisse at normalesup dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |marc dot glisse at
| |normalesup dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2006-04-18 15:10 ` marc dot glisse at normalesup dot org
@ 2006-04-18 17:49 ` pcarlini at suse dot de
2006-04-19 11:09 ` marc dot glisse at normalesup dot org
` (10 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: pcarlini at suse dot de @ 2006-04-18 17:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #18 from pcarlini at suse dot de 2006-04-18 17:49 -------
Probably this PR should be suspended, while waiting for the resolution of DR
456:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2006-04-18 17:49 ` pcarlini at suse dot de
@ 2006-04-19 11:09 ` marc dot glisse at normalesup dot org
2006-04-19 11:20 ` pcarlini at suse dot de
` (9 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: marc dot glisse at normalesup dot org @ 2006-04-19 11:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #19 from marc dot glisse at normalesup dot org 2006-04-19 11:09 -------
(In reply to comment #18)
> Probably this PR should be suspended, while waiting for the resolution of DR
> 456:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456
Whether the situation remains the same or the g++ implementation becomes legal
does not change the fact that it would be nice (and not at all out of reach) to
use the features of glibc and solaris (any others?) that allow a cleaner global
namespace when including a <cxxx> header, it would just lower the priority of
this from bug to wishitem. And for platforms where it is not possible, then the
current implementation will have to remain, whatever the committee decides.
But if you want to suspend it, it is your call...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2006-04-19 11:09 ` marc dot glisse at normalesup dot org
@ 2006-04-19 11:20 ` pcarlini at suse dot de
2006-04-19 11:38 ` marc dot glisse at normalesup dot org
` (8 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: pcarlini at suse dot de @ 2006-04-19 11:20 UTC (permalink / raw)
To: gcc-bugs
------- Comment #20 from pcarlini at suse dot de 2006-04-19 11:19 -------
(In reply to comment #19)
> (In reply to comment #18)
> > Probably this PR should be suspended, while waiting for the resolution of DR
> > 456:
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456
>
> Whether the situation remains the same or the g++ implementation becomes legal
> does not change the fact that...
I disagree, for many reasons. The issue is more complex, really. For instance -
assuming of course the current implementation becomes completely legal - then
changing the behavior for some targets and not for others, implies that the
very same source code would not be be portable across those targets. I don't
think we would like that. Besides, more generally, I'm not at all sure that all
the users would actually *like* the new behavior. Indeed, to my best knowldege
some implementations which, in principle, could rather easily implement the
current standard mandated behavior (for many reasons, for instance are
targeting only a small set of systems) decided to *not* implement it by
default, on purpose.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2006-04-19 11:20 ` pcarlini at suse dot de
@ 2006-04-19 11:38 ` marc dot glisse at normalesup dot org
2006-04-30 23:05 ` Gabriel Dos Reis
2006-04-19 11:44 ` pcarlini at suse dot de
` (7 subsequent siblings)
14 siblings, 1 reply; 17+ messages in thread
From: marc dot glisse at normalesup dot org @ 2006-04-19 11:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #21 from marc dot glisse at normalesup dot org 2006-04-19 11:38 -------
(In reply to comment #20)
> the
> very same source code would not be be portable across those targets. I don't
> think we would like that. Besides, more generally, I'm not at all sure that
> all the users would actually *like* the new behavior.
I meant proposing it as a choice, with a flag like -fclean-global-namespace
(better than a macro since it probably means changing the include path and
redefining a few macros), which needs not be the default. The current
implementation would have to be kept for some platforms anyway, so it could be
kept for all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Bug libstdc++/6257] C-library symbols enter global namespace
2006-04-19 11:38 ` marc dot glisse at normalesup dot org
@ 2006-04-30 23:05 ` Gabriel Dos Reis
0 siblings, 0 replies; 17+ messages in thread
From: Gabriel Dos Reis @ 2006-04-30 23:05 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
"marc dot glisse at normalesup dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| (In reply to comment #20)
| > the
| > very same source code would not be be portable across those targets. I don't
| > think we would like that. Besides, more generally, I'm not at all sure that
| > all the users would actually *like* the new behavior.
|
| I meant proposing it as a choice, with a flag like -fclean-global-namespace
That is a non-starter.
PR better suspended.
-- Gaby
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2006-04-19 11:38 ` marc dot glisse at normalesup dot org
@ 2006-04-19 11:44 ` pcarlini at suse dot de
2006-04-22 2:09 ` pinskia at gcc dot gnu dot org
` (6 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: pcarlini at suse dot de @ 2006-04-19 11:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from pcarlini at suse dot de 2006-04-19 11:44 -------
(In reply to comment #21)
> I meant proposing it as a choice, with a flag like -fclean-global-namespace
> (better than a macro since it probably means changing the include path and
> redefining a few macros), which needs not be the default. The current
> implementation would have to be kept for some platforms anyway, so it could be
> kept for all.
Ok, this makes sense, assuming of course it can be done in a reasonably clean
way. I encourage you to try preparing something self-contained (not necessarily
complete, not necessarily touching all the headers, at this stage) and post it
for further discussion on the libstdc++ list. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2006-04-19 11:44 ` pcarlini at suse dot de
@ 2006-04-22 2:09 ` pinskia at gcc dot gnu dot org
2006-04-30 23:05 ` gdr at integrable-solutions dot net
` (5 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-04-22 2:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from pinskia at gcc dot gnu dot org 2006-04-22 02:09 -------
*** Bug 27255 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |trentgamblin at hotmail dot
| |com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2006-04-22 2:09 ` pinskia at gcc dot gnu dot org
@ 2006-04-30 23:05 ` gdr at integrable-solutions dot net
2006-04-30 23:06 ` [Bug libstdc++/6257] [DR 456] " pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: gdr at integrable-solutions dot net @ 2006-04-30 23:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from gdr at integrable-solutions dot net 2006-04-30 23:05 -------
Subject: Re: C-library symbols enter global namespace
"marc dot glisse at normalesup dot org" <gcc-bugzilla@gcc.gnu.org> writes:
| (In reply to comment #20)
| > the
| > very same source code would not be be portable across those targets. I
don't
| > think we would like that. Besides, more generally, I'm not at all sure that
| > all the users would actually *like* the new behavior.
|
| I meant proposing it as a choice, with a flag like -fclean-global-namespace
That is a non-starter.
PR better suspended.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2006-04-30 23:05 ` gdr at integrable-solutions dot net
@ 2006-04-30 23:06 ` pinskia at gcc dot gnu dot org
2007-06-16 22:07 ` pcarlini at suse dot de
` (3 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-04-30 23:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #25 from pinskia at gcc dot gnu dot org 2006-04-30 23:06 -------
Suspending based on the Defect report being still open.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |SUSPENDED
Summary|C-library symbols enter |[DR 456] C-library symbols
|global namespace |enter global namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2006-04-30 23:06 ` [Bug libstdc++/6257] [DR 456] " pinskia at gcc dot gnu dot org
@ 2007-06-16 22:07 ` pcarlini at suse dot de
2007-06-16 22:19 ` pcarlini at suse dot de
` (2 subsequent siblings)
14 siblings, 0 replies; 17+ messages in thread
From: pcarlini at suse dot de @ 2007-06-16 22:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #26 from pcarlini at suse dot de 2007-06-16 22:07 -------
*** Bug 32371 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |olifant at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2007-06-16 22:07 ` pcarlini at suse dot de
@ 2007-06-16 22:19 ` pcarlini at suse dot de
2008-12-15 18:47 ` paolo dot carlini at oracle dot com
2010-02-05 13:16 ` paolo dot carlini at oracle dot com
14 siblings, 0 replies; 17+ messages in thread
From: pcarlini at suse dot de @ 2007-06-16 22:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #27 from pcarlini at suse dot de 2007-06-16 22:19 -------
I think the resolution of DR 456 (now [WP]):
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#456
means our behavior is now conforming to the amended Standard.
--
pcarlini at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2007-06-16 22:19 ` pcarlini at suse dot de
@ 2008-12-15 18:47 ` paolo dot carlini at oracle dot com
2010-02-05 13:16 ` paolo dot carlini at oracle dot com
14 siblings, 0 replies; 17+ messages in thread
From: paolo dot carlini at oracle dot com @ 2008-12-15 18:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #28 from paolo dot carlini at oracle dot com 2008-12-15 18:42 -------
*** Bug 38531 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mayor1 at uralweb dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug libstdc++/6257] [DR 456] C-library symbols enter global namespace
[not found] <bug-6257-4079@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2008-12-15 18:47 ` paolo dot carlini at oracle dot com
@ 2010-02-05 13:16 ` paolo dot carlini at oracle dot com
14 siblings, 0 replies; 17+ messages in thread
From: paolo dot carlini at oracle dot com @ 2010-02-05 13:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #29 from paolo dot carlini at oracle dot com 2010-02-05 13:16 -------
Given the resolution of DR 456 [CD1], this is invalid, that is, the snippet can
well compile (and does, with libstdc++-v3).
--
paolo dot carlini at oracle dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
^ permalink raw reply [flat|nested] 17+ messages in thread