This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: selective linking of floating point support for *printf / *scanf

On Wed, 3 Sep 2014, Joern Rennecke wrote:

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]