This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fixing namespace issues for variables
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 23 Oct 2015 13:57:14 -0700 (PDT)
- 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> <alpine dot DEB dot 2 dot 10 dot 1510232022460 dot 5421 at digraph dot polyomino dot org dot uk>
> 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.
Those are a case where we don't have quite as much concern for application
compatibility, because they were traditionally macros (and not even
lvalues) and so no portable application expects them to be available as
identifiers for other purposes. However, they do highlight another
compatibility issue I'd forgotten about. Traditionally, stdin et al were
values that could be used in static initializers ("FILE *out = stdout;" at
top level, for example). That's already not the case in glibc, so we don't
have to worry about that exact case. But "&stdin" et al are constants today.
In your proposal, "&foo" would not be a constant any longer. We have to
figure out for each affected variable whether that change would be
conformant, and whether it would break application code.