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 21:23:52 +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> <alpine dot DEB dot 2 dot 10 dot 1510232022460 dot 5421 at digraph dot polyomino dot org dot uk> <20151023205715 dot 09EA22C3B7D at topped-with-meat dot com>
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