Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf

[Joseph S. Myers]

On Wed, 3 Sep 2014, Joern Rennecke wrote:

> On 2 September 2014 16:28, Joseph S. Myers <address@hidden> 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
address@hidden