This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: selective linking of floating point support for *printf / *scanf
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Joern Rennecke <joern dot rennecke at embecosm dot com>
- Cc: Joey Ye <joey dot ye dot cc at gmail dot com>, Thomas Preud'homme <thomas dot preudhomme at arm dot com>, Grissiom <chaos dot proton at gmail dot com>, Eric Blake <eblake at redhat dot com>, GCC <gcc at gcc dot gnu dot org>, Joerg Wunsch <joerg_wunsch at uriah dot heep dot sax dot de>, <avr-libc-dev at nongnu dot org>, Andrew Burgess <andrew dot burgess at embecosm dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Wed, 3 Sep 2014 20:04:17 +0000
- Subject: Re: selective linking of floating point support for *printf / *scanf
- Authentication-results: sourceware.org; auth=none
- References: <CAMqJFCpWKXVmmc-YLKf9XO6H8C_YnTEcgzkJAidE21MirJbi-w at mail dot gmail dot com> <001401cfc0f9$bdc5cbc0$39516340$ at arm dot com> <CAMqJFCrEOgavwvW25vO=S-+0TZ_xOnDa0Ex-Ff4XG329K5WE9g at mail dot gmail dot com> <001901cfc1c4$d0678630$71369290$ at arm dot com> <CAMqJFCoFC8sVRQB3+v4dzSVc5LLs9cycjm621FmM34gGHRWFng at mail dot gmail dot com> <000001cfc1e3$7f1a22f0$7d4e68d0$ at arm dot com> <CAMqJFCo1EA8TLVsv=r7gW-udiH6pqBKVuQUvHeGcFDqrnMo_EQ at mail dot gmail dot com> <000101cfc281$3a3008f0$ae901ad0$ at arm dot com> <CAMqJFCrrj1_VHmz7G-VgDpLNGjsTtdjPLqbCRY1oVxeO-BESHw at mail dot gmail dot com> <000201cfc34f$1ceadb20$56c09160$ at arm dot com> <54007E28 dot 6090106 at redhat dot com> <CALC6sNDiJ+EOjTasMj2YCQmq10mVQrZKKsaUurhjQe=Zbn435g at mail dot gmail dot com> <000401cfc40a$a22255f0$e66701d0$ at arm dot com> <CAL0py26WdXN0N-jhejLAbEjZ-Q5xT6yunr1gnmcBhvpFPaVEfw at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1409021521370 dot 27793 at digraph dot polyomino dot org dot uk> <CAMqJFCqHW5kgOjDPcmPffFO8fxCDMoLChFqtL9yyEsKbkZGz+A at mail dot gmail dot com>
On Wed, 3 Sep 2014, Joern Rennecke wrote:
> On 2 September 2014 16:28, Joseph S. Myers <joseph@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
joseph@codesourcery.com