Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf
> From: Joseph S. Myers [mailto:jos...@codesourcery.com] > Sent: Tuesday, September 02, 2014 11:29 PM > > 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. Ah yes, I mistook file scope with file scope with internal linkage. So then there shouldn't be any problem since _printf_float and _scanf_float are only used for external linkage, no macro refer to them. Best regards, Thomas ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] selective linking of floating point support for *printf / *scanf
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? ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
Re: [avr-libc-dev] 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 jos...@codesourcery.com ___ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
