[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] selective linking of floating point support for *prin
Joseph S. Myers
Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf
Wed, 3 Sep 2014 20:04:17 +0000
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
Joseph S. Myers