Consider rebasing your printf fork of mpaland/printf on eyalroz/printf #2694

Open
opened 2025-10-11 16:55:05 -05:00 by eyalroz · 4 comments
eyalroz commented 2025-10-11 16:55:05 -05:00 (Migrated from github.com)

Hello RaspberryPI pico-SDK people,

It's been pointed out to me that your SDK's standalone print implementation is a copy, or fork, of Marco Paland standalone printf library code.

Well, as you may be aware, Mr. Paland had abandoned his repository over 5 years ago; but - development work has continued, in my own eyalroz/printf: A lot of bugs have had fixes integrated from other forks, or just fixed, period; output correctness has been improved (mpaland's code was failing in all sorts of combinations of flags and format specs) as well as features added - almost completing the C99 feature set.

I therefore suggest you consider rebasing your code onto the eyalroz/printf implementation.

I should perhaps mention that the embeddedartistry Arduino SDK has rebased from mpaland/printf to eyalroz/printf.

Hello RaspberryPI pico-SDK people, It's been pointed out to me that your SDK's [standalone print implementation](https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_printf/printf.c) is a copy, or fork, of [Marco Paland standalone printf library](https://github.com/mpaland/printf) code. Well, as you may be aware, Mr. Paland had abandoned his repository over 5 years ago; but - development work has continued, in my own [eyalroz/printf](https://github.com/eyalroz/printf): A _lot_ of bugs have had fixes integrated from other forks, or just fixed, period; output correctness has been improved (mpaland's code was failing in all sorts of combinations of flags and format specs) as well as features added - almost completing the C99 feature set. I therefore suggest you consider rebasing your code onto the eyalroz/printf implementation. I should perhaps mention that the embeddedartistry [Arduino SDK](https://github.com/embeddedartistry/arduino-printf) has rebased from [mpaland/printf](https://github.com/mpaland/printf) to [eyalroz/printf](https://github.com/eyalroz/printf).
LukeShu commented 2025-10-14 13:33:25 -05:00 (Migrated from github.com)

Might help with merging the Pico-SDK changes with changes in another repo: I've done some Git-fu to pull the Pico-SDK changes back out onto Marco's commit history: https://github.com/LukeShu/pico-fmt/tree/pico-sdk

Might help with merging the Pico-SDK changes with changes in another repo: I've done some Git-fu to pull the Pico-SDK changes back out onto Marco's commit history: https://github.com/LukeShu/pico-fmt/tree/pico-sdk
kilograham commented 2025-10-29 11:50:17 -05:00 (Migrated from github.com)

Awesome, thanks - we'll look at updating this is the next minor release; though we do need to be wary of growing the printf library unconditionally (if the new code is bigger) since a lot of existing things may use printf and be tight on space.

Awesome, thanks - we'll look at updating this is the next minor release; though we do need to be wary of growing the printf library unconditionally (if the new code is bigger) since a lot of existing things may use printf and be tight on space.
eyalroz commented 2025-10-29 13:56:20 -05:00 (Migrated from github.com)

@kilograham : About code size...

  • I have made as much functionality as users have found relevant to be opt-out at compile time, with 5 independent Yes/No flags for different functionality, and a choice of internal numerical representation (double vs single precision).
  • I have aimed to avoid expansion through adhering to reuse of the same code by different printf-family functions, using some generic gadgetry. I trust that when compiling with -Os, the result is pretty small.

That said - I did not engage in minute optimizations for minimizing size, so I suppose it is up to you to consider the resulting size. I hope this works out :-)

@kilograham : About code size... * I have made as much functionality as users have found relevant to be opt-out at compile time, with 5 independent Yes/No flags for different functionality, and a choice of internal numerical representation (double vs single precision). * I have aimed to avoid expansion through adhering to reuse of the same code by different printf-family functions, using some generic gadgetry. I trust that when compiling with `-Os`, the result is pretty small. That said - I did not engage in minute optimizations for minimizing size, so I suppose it is up to you to consider the resulting size. I hope this works out :-)
kilograham commented 2025-10-29 15:30:59 -05:00 (Migrated from github.com)

Ah, sweet! The float internal representation option might be super cool too - since the old version always pulled in double

Ah, sweet! The float internal representation option might be super cool too - since the old version always pulled in double
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk#2694
No description provided.