Fixing namespace issues for variables

[Joseph Myers]

On Fri, 23 Oct 2015, Roland McGrath wrote:

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

Well, portable code can't use &stdin, because it's simply not valid with a 
traditional definition of stdin as (&_iob[0]).  The standard says the std* 
macros are expressions of type "pointer to FILE", with no requirements on 
being constant, able to have their address taken, etc.

-- 
Joseph S. Myers
joseph@codesourcery.com