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

[Joern Rennecke <joern dot rennecke at embecosm dot com>]

On 28 August 2014 06:30, Thomas Preud'homme <thomas.preudhomme@arm.com> wrote:

>> Yes.  I'll have to adjust the avr hook that it'll leave the v*printf /
>> v*scanf functions
>> alone - at least by default / for ISO C behaviour - but it'll give me
>> an easy way
>> to add a switch to tweak the behaviour.
>>
>> Or maybe we can use a -f option to select the v*printf / v*scanf default and
>> put the a stdio_altname__int_ target hook in targhooks.c, to be shared by all
>> configs that want an __int_ prefix.
>
> Are you aware of other C libraries that would benefit from such a default

No.  I haven't been looking for it, either.

> (newlib
> wouldn't)?

Well, to avoid namespace pollution, you need a different name used by
the compiler
than iprintf - see below.
>

>
> Right now I'm having trouble to define stdio_altname in newlib-c.c since this would
> require it to be a C target hook but such a hook cannot be called from middle end.

Hmm, yes, this is not exactly C specific.  Although printf / scanf are
part of the C
library, other languages may use the C runtime library.
Likewise, builtin functions are not considered exclusive to C.
So it should be a general target hook, in a target-, but not
language-specific file.

>> FWIW, to safely shift the symbol into the implementation namespace you
>> need a prefix that starts with two underbars or one underbar and a
>> capital letter.
>> Or use some funny non-standard character in the symbol - but that's asking
>> for
>> more portability issues.
>> For references made automatically by gcc, it's a good idea not to impinge on
>> the application namespace.
>
> I'll consider about renaming the symbol but we've been using this one for
> some time in our toolchain so it might not be possible to change.

So are you saying you are stuck with printf_float?

But at least for iprintf and friends, the only requirement is that
newlib provides
a definition.  There is no need for gcc to use these symbols to implement ISO C
*printf functions.


>> An application might use printf from <stdio.h>, but define its own functions
>> iprintf, printf_float and _printf_float.
>> Therefore, it's a good idea to put the definition of newlib's iprintf
>> in a separate
>> file from __int_printf.  Having essentialy the same contents, but
>> defining a different
>> symbol, and let the linker match them up to the definition.
>
> I'm confused here. Why would we have a __int_printf? Right now we only
> have iprintf as an alias to printf, _printf_float being a weakly defined function
>  called from printf for the float support.

The user writing including stdio.h, using iprintf, and not defining is
one thing; in this
case, the expectation is that the definition comes from newlib.

However, when the user uses printf, (s)he is still entitles to define a function
iprintf and is entitled to expect that these don't interfere with each other;
hence, gcc should not emit calls to iprintf when it sees a call to printf;
using a name in the implementation namespace solves this issue.
However, defining this in the same file as iprintf is not safe, as then you'd
pull in the iprintf definition as well.  Even if it's a weak alias,
what if the user
defined a weak iprintf?