This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 26 August 2014 07:48, Thomas Preud'homme <> wrote:
> What happens in the case that a program contains both some printf and
> __int_printf call?

Due to the library order defined in the specs, the float-enbled printf
definition will
be picked up from libprintf_flt.a .

> I didn't do extensive yet but it seems you miss the case of variadic functions.
> Consider the example in attachment: two calls to __int_printf will be
> generated yet my_printf could be called with the format string "%f\n".

That testcase is not valid. You'd to use one of the v*printf functions.
Solving the general problem for these is not computable; for specific cases, it
would be possible, but at the cost of varying degrees of complexity.
So I let this for manual selection: it's not handled with the
hook, and you have to use a special link line to use the integer-only
Well, if desired, a spec change could give an option to do that.

Another extension possibility in this area is to have the library also
provide forwarder
stubs for __int_v*printf in libc, so you could use the latter function
whenever you deem
fit, and the linker will sort out which implementation you get.

> As to the patch it seems to me the macro should be per library, not per backend.
> Else two backend supporting newlib would need to write the same code twice.

That can be implemented with suitable *newlib*.[ch] files that are
selected in config.gcc,
akin to newlib-stdint.h and glibc-c.c .

> I'll also try to think how to support the new scheme for printf with float in newlib.
> As I said it relies on printf calling _printf_float that is a weak symbol. Previous
> scheme could pull 2 implementations of printf and consume more size. The
> problem is that compiling newlib with automatic selection would detect some case
> where float might be needed (variadic functions) and define _printf_float
> accordingly.

Well, all the *printf functions are variadic, and as stated above,
your example is invalid.
The wildcard are va_list taking functions.  You first have to decide
what you want to
happen with these by default, and what kind of non-default behaviour
you'd like to be
able to select, and how; than we can talk about if this neeeds any
extra infrastructure
to implement.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]