On Wed, 3 Sep 2014, Joern Rennecke wrote: > On 2 September 2014 16:28, Joseph S. Myers <jos...@codesourcery.com> wrote: > > On Tue, 2 Sep 2014, Joey Ye wrote: > > > >> Apparently newlib is not following this specification very well, as > >> there are symbols like _abc_r defined every where in current newlib. I > >> am not implying the spec should not be followed, but is newlib > >> designed to have a loose spec for the single underscore? > > > > Identifiers beginning with a single underscore are reserved with file > > scope. This means an application cannot provide an external definition of > > them, because such an external definition would have file scope. So it's > > fine for the implementation to define such identifiers and use them in the > > implementation of standard functions. > > Hmm, this trows up another question how in GNU C, extensions interact with > the putatively unchanged parts of the standard. > If a user program defines an assembler name for a global function which is > different from the name used in the source code, is that assembler name > used at file scope? It would seem to me it's only used at global/link scope. > As such, is the use of _[a-z].* as assembly names then part of the > user namespace?
I see no reason a standard header shouldn't be able to define _[a-z] static functions at file scope, so I think it should be presumed that such names as assembly names are part of the implementation namespace. That's certainly the case for names such as _a.1 that GCC can generate for block-scope static variables called _a: if you generate such assembler names yourself, you risk conflicting with ones generated by GCC for block-scope statics. -- Joseph S. Myers jos...@codesourcery.com
