Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

print_number() non guaranteed to be thread safe with floating point numbers #853

Open
escherstair opened this issue May 8, 2024 · 0 comments

Comments

@escherstair
Copy link

print_number() seems to be an innocuous function because it prints a number into a string.
Is uses sprintf (with different format specifiers "%d", "%1.15g", ... depending on the type) and so everything seems fine.
But there is a big elephant in the room.
Implementation of sprintf depends on the toolchain, and in the embedded world it would be one of newlib, newlib-nano, redlib, ... or something like that.
Unfortunately, some of these implementations could call some malloc/calloc/realloc under the hood and this is a big issue when a RTOS is used.
newlib calls allocators while formatting floating point numbers (not for integers).
cJSON knows perfectly this problems with allocators and RTOS, and it provides cJSON_InitHooks to customize allocators.
But there is no control over the allocators called by sprintf (as an example).

Long story short: formatting floating point numbers with newlib and RTOS cannot work.
If you're interested you can read here

I think that cJSON should not depend on sprintf allocators, but include a working implementation of sprintf for floating point numbers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant