Fixing namespace issues for variables

[Roland McGrath]

> 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.