Short term fix for conflicting types for 'tfp_printf'

[zvecr]

Description

When adding encoders to a board, while console is enabled, the following error is thrown

Compiling: quantum/encoder.c                                                                       In file included from tmk_core/common/print.h:76:0,
                 from tmk_core/common/debug.h:22,
                 from quantum/keymap.h:35,
                 from quantum/quantum.h:30,
                 from quantum/encoder.h:20,
                 from quantum/encoder.c:18:
tmk_core/common/chibios/printf.h:107:16: error: conflicting types for 'tfp_printf'
 #define printf tfp_printf
                ^
tmk_core/common/chibios/printf.h:102:6: note: previous declaration of 'tfp_printf' was here
 void tfp_printf(char* fmt, ...);
      ^~~~~~~~~~
tmk_core/common/chibios/printf.h:108:17: error: conflicting types for 'tfp_sprintf'
 #define sprintf tfp_sprintf
                 ^
tmk_core/common/chibios/printf.h:103:6: note: previous declaration of 'tfp_sprintf' was here
 void tfp_sprintf(char* s, char* fmt, ...);
      ^~~~~~~~~~~
 [ERRORS]

The route cause, tfp_printf/tfp_sprintf gets a macro alias to increase compatibility, however the signature of the tfp versions are not compliant.

For reference, ive used http://www.cplusplus.com/reference/cstdio/printf/ and http://www.cplusplus.com/reference/cstdio/snprintf/, to update tmk_core/common/chibios/printf.h.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[zvecr]

Was a void before, so no one can be checking the return code....

Question is, while not perfect, will this do?

[fauxpark]

According to this: http://www.cplusplus.com/reference/cstdio/printf/ the standard seems to be to return the number of characters written, or a negative number if unsuccessful. If tfp_format() keeps track of that already, we could just change its return type too, and use that. Though I don't know how useful this information is, so returning 1 for now might be good enough.

[zvecr]

It would be a more invasive change, things like uli2a would need to be updated to return a count of written characters, then tfp_format would need keep the tally. tfp_sprintf could potentially return strlen of the output buffer if it wants to be slightly more accurate. To be 100% compliant, we would need to do all the extra error handling.

At the moment, I kinda just want my board to compile... though I do see long term value in it being feature complete.

[fauxpark]

I wonder if we can use this fork of tinyprintf instead: https://github.com/cjlano/tinyprintf
It seems to have fixed a few bugs and added more functions, plus tfp_sprintf() returns the number of characters already!

[zvecr]

Still has the tfp_printf void issue, and we would need to port the binary support into it. Worth considering, plus theres alternatives like https://github.com/mpaland/printf which tick both non void functions and binary support.

Edit: prepared a branch with the mpaland implementation https://github.com/qmk/qmk_firmware/compare/master...zvecr:feature/mpaland_printf?expand=1, seems to work fine with brief testing but it does increase chibios based firmware by 750 bytes.