This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: selective linking of floating point support for *printf / *scanf
- From: Joern Rennecke <joern dot rennecke at embecosm dot com>
- To: "Joseph S. Myers" <joseph at codesourcery 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:26:57 +0100
- 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>
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?