This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fixing namespace issues for variables
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 23 Oct 2015 20:33:14 +0000
- Subject: Re: Fixing namespace issues for variables
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1510222324130 dot 23141 at digraph dot polyomino dot org dot uk> <20151023002929 dot 946ED2C3B50 at topped-with-meat dot com> <alpine dot DEB dot 2 dot 10 dot 1510230210470 dot 23141 at digraph dot polyomino dot org dot uk> <20151023181705 dot 3E1C02C3B7A at topped-with-meat dot com>
On Fri, 23 Oct 2015, Roland McGrath wrote:
> > re_syntax_options (bug 18442) may be a more straightforward case for this
> > fix, as a pure GNU extension.
>
> Well, it's simpler only in the sense that there is no conformance issue to
> think about. It's probably also less sensitive in that the likelihood that
> this identifier is in use in existing application code seems low off hand.
> But I think the primary concern for all the cases is whether it's really OK
> to effectively reserve an identifier for all purposes rather than just for
> external linkage when that identifier was previously available for other uses.
The third case of this issue is stdin, stdout, stderr. They are already
macros, unambigously reserved as such - the issue for them (bug 17576)
being that the existing "#define stdin stdin" with "extern struct _IO_FILE
*stdin;" is also using them with external linkage when they aren't
reserved with external linkage, at least if <stdio.h> isn't included.
But as by far the most widely used variables with this issue, and the ones
with the most existing ABI complexity around them, a fix for them
certainly shouldn't be considered straightforward at all.
--
Joseph S. Myers
joseph@codesourcery.com