PRINTF_ALIAS_STANDARD_FUNCTION_NAMES is ambiguous

[grassead]

I don't understand weel the expected behviour of the PRINTF_ALIAS_STANDARD_FUNCTION_NAMES option.

What I expect is that option will overrride the 'printf' function (and other ones) from the libc to reroute call to the lib functions.

But, from the code, we can see that "
# define printf_ printf
"
that exactly do the reverse (the lib's printf_ call the libc printf).
It should be

# define printf printf_

Thanks

[eyalroz]

Hello @grassead. First, thank you for filing an issue.

I think you're misunderstanding what the aliasing is supposed to do. With the aliasing as defined right now, the library doesn't expose the functions printf_, sprintf_ etc. - it exposes printf(), sprintf() etc. Why? Because as the compiler reads the library code, it takes away the underscores, i.e. the library defines alternatives to the stdio.h functions. I do not want people's own code to have to use this macro; it would be confusing.

[grassead]

Thanks for the explanation.

[eyalroz]

@grassead : NP. If you happen to use the library for something interesting - do let me know :-)

[phillipjohnston]

Note that the reversed aliasing direction does cause problems, as you have seen reported before with GCC optimizing some printf call formats in a way that causes printing to appear broken. I received enough complaints about this that I simply reversed directions back to the previous approach. If you want to use this library, you likely don't want to use the compiler's optimizations based on the assumption that the full stdio.h implementation is available, since it is going to try to substitute putchar or puts in some situations, and this library does not provide those functions. (I'm aware that this can be disabled with a compiler flag).

I'm not following the explanation above in such a way that I can see benefits to the current direction, but maybe I'm missing something obvious. For example, if I actually wanted the compiler's optimizations based on the assumption I have the other functions implemented, that would be a reason to use the current approach.

[eyalroz]

I'm not following the explanation above in such a way that I can see benefits to the current direction

The benefit is that, when using the library, you don't have to apply any macros. This approach makes the library a proper drop-in for the <stdio.h> functions. Well, ignoring the compiler optimizations which remove the calls.

The other direction does cause problems for people in other scenarios. For example, if you're using C++, and have an identifier in a namespace that's identical to an stdio.h function name, then your program may fail to compile.

Still, considering what you've described, I'm wondering what to do. Do you think I should, perhaps, offer both directions of aliasing?

[phillipjohnston]

I did not consider the stdio.h drop-in aspect (which I imagine as having a file compile/link properly even if it doesn't include printf.h), I was blinded by the fact that a) my libc includes printf.h as part of stdio.h and focused on the other side of the equation, and b) it's used on Arduino via a header I control.

To be clearer on what I think would be useful, (in addition to the current option) have some option in printf.h so you can apply these definitions to source files that include printf.h. I have no comment on the proper interpretation of aliasing or what the proper name for this will be :).

# define printf    printf_
 # define sprintf   sprintf_
 # define vsprintf  vsprintf_
 # define snprintf  snprintf_
 # define vsnprintf vsnprintf_
 # define vprintf   vprintf_

[eyalroz]

@phillipjohnston : The possibility I'm mulling over is have the aliasing CMake option have three values: None, the way aliasing is done right now, and the way you described (which is what mpaland's library used to offer). It's not that difficult to implement (I think), but I'm wondering whether two kinds of aliasing would be too confusing.

Also, would appreciate your thoughts about the "defensive UB" I'm considering for issue #140.

[eyalroz]

Try out the new 6.1.0 RC1 release page which supports both aliasing modes.