On 26 August 2014 07:48, Thomas Preud'homme <thomas.preudho...@arm.com> 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 calls.stdio_altname hook, and you have to use a special link line to use the integer-only implementations. 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.
