LLVM clang 4.0.3 compliation - "%g is unsupported"

Hi,
Hope to get some help.
I included the parson files in a project I am working on, started writing it on a debian linux environment, all works fine.
Then I used the files (with malloc and free adaptation) to an embedded BG96 module that is complied using LLVM 4.0.3 clang, all compiles and links great.
When using it with JSON that keys and values are all string, all is working fine.
When trying to use it with a simple function of json_parse_string() and the string has value/s of type number then the program hangs up and halts.
Another symptom is when using json_object_set_number() and later on trying to print it serialized, or to save it to a file, then the value entry of the key shows "%g is unsupported".
Any idea on what might be the issue and how to resolve it ?
I would appreciate any assistance on overcoming this, zarie3@gmail.com.
Thanks
Arie

I can't find any info about clang 4.0.3 so it looks like you're using some fork maybe? It should work with %g however. You could try editing this line:

parson/parson.c

Line 66 in fd77bcd

    
           #define FLOAT_FORMAT "%1.17g" /* do not increase precision without incresing NUM_BUF_SIZE */

to

#define FLOAT_FORMAT "%f" /* do not increase precision without incresing NUM_BUF_SIZE */

Please tell me if this helps.

Hi kgabis,
Thank you for your reply.
I tried this, however the BG96 module printf implementation does not support %g %f at all.
I worked it out "dirty" as the project does not work on scientific numbers and precision is not highly required.
int fruc = (int)((num - (int)num) * 1000);
if (fruc)
written = sprintf(num_buf, "%d.%d", (int)num, fruc);
else
written = sprintf(num_buf, "%d", (int)num);

The other problem that I got that when parsing a value of number (parse_number_value) the whole system got stuck, it was related to "errno" and strtod.
At the moment the statement executed "errno = 0;" the system hang up.
So we shall not rely on errno and shall work it out with out it.
After these two changes the library works fine on BG96 embedded (with ThreadX);

Thank you for your work, and support.

Should be "%d.%03d"

Thanks for the update, unfortunately I don't see a way of handling this in the library.