printf(%c, x) : pulling in libg_nano stuff ?

[fenugrec]

Hi,
I'm most likely something wrong here, I'm not sure...

#include <stdbool.h>
#include <string.h>

#include "printf_config.h"	//just to get PRINTF_ALIAS_STANDARD_FUNCTION_NAMES...
#include <printf/printf.h>

.........
			printf("eos_string: 0x");
			//printf("%c", eot_char);

I'm compiling this for embedded (ARM CM0) targets with nano.specs etc, and everything works as expected until I uncomment that second printf : then the linker tries to locate a bunch of libc stubs that are missing , e.g. _sbrk , _write_r, _seek_r etc (as I would expect if I was using the stdio printf ).
Is there anything special about using the "%c" specifier on its own ? If I replace that second printf with a %d , it'll work... Or if I change the formatter as " %c (i.e. adding a space in front), that also works fine !

[eyalroz]

Is there anything special about using the "%c" specifier on its own ?

Nope, nothing special about it. Also, as you know, the only things the library takes from the standard library are the definitions in:

#include <stdbool.h>
#include <stdint.h>

and that's that.

If I replace that second printf with a %d , it'll work... Or if I change the formatter as " %c (i.e. adding a space in front), that also works fine !

Could it perhaps be some special optimization in your compiler? Maybe it replaces printf("%c") with putchar()?

[fenugrec]

Could it perhaps be some special optimization in your compiler? Maybe it replaces printf("%c") with putchar()?

10/10 . I just checked the disassembly of the .o for that module and that's exactly what is happening. Thanks !

Of course I can put putchar_() there myself but I'll try to find a "clean" way to do this. Maybe alias putchar() to putchar_ or something.

[eyalroz]

Actually, you should file this as a bug with your compiler author, because they should be making sure that the printf() they're optimizing away is from libg_nano - otherwise their optimization doesn't make sense.

[fenugrec]

Maybe... I notice it does the same thing with a printf() with no formatters, replacing it with puts()... usually gcc bug reports for embedded stuff like this falls on deaf ears though.
[EDIT ] the easier solution is to pass -fno-builtin-printf .

[eyalroz]

@fenugrec : If you file it, I'll comment favorably and upvote :-)

Anyway, I know they take a long while to handle bugs, but then a few years later, it sometimes happens. Think of it is a s a civic duty.

[kjsdf7wr3]

@eyalroz I ran into the same issue today when using printf("%s\n", str); which gets replaced by puts(str);.
I think it makes sense to mention -fno-builtin-printf somewhere in the README or add a wiki.

[eyalroz]

@kjsdf7wr3 :

1. Which compilers support -fno-builtin-printf?
2. Which compiler were you using? The compiler should not do this if the source file has not, at the very least, included stdio.h .

[fenugrec]

1. Which compilers support `-fno-builtin-printf`?

At least gcc and clang

I'm fairly certain I did not have an #include <stdio.h> in there. With gcc, I think this due to the following:

The ISO C90 functions [......] printf, putchar, puts, ..... are all recognized as built-in functions unless -fno-builtin is specified (or -fno-builtin-function is specified for an individual function).

Some other functions may/may not be recognized as builtins in certain "strict ISO C modes" (-ansi, -std=c90, -std=c99 or -std=c11) , I haven't explored this.

[eyalroz]

@fenugrec , @kjsdf7wr3 : Please try pulling branch fix-issue-76, to check whether it resolves the problem. I'll also add a README.md note.

[fenugrec]

Cannot test easily here (I'm not using the CMakeLists from this project, and just passing -fno-builtin-printf globally ) but your method seems reasonable; I assume it works on your setup ?