use the MAX constants from <float.h>?

[iweindesmedt]

compiler warns with
cJSON.c:170:4: warning: floating constant exceeds range of 'double' [-Woverflow]

i think it might be better to use the constants defined in <float.h> throughout the code, like DBL_MAX, etc...

[hustanhuang]

(maybe not relevant to this issue)

could you please provide your compiler version?
because I can't get the same warning with my -Woverflow option on

*** at *** in ~/t/cJSON> clang -c cJSON.c -Wall -Woverflow
*** at *** in ~/t/cJSON> ls
CMakeLists.txt Makefile       README.md      cJSON.h        cJSON_Utils.c  test.c         tests
LICENSE        README         cJSON.c        cJSON.o        cJSON_Utils.h  test_utils.c
*** at *** in ~/t/cJSON>

my compiler version:

*** at *** in ~/t/cJSON> clang -v
Apple LLVM version 7.3.0 (clang-703.0.31)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[iweindesmedt]

sure, XC32 (v1.42) http://www.microchip.com/xc32, its for embedded systems

[DaveGamble]

Out of interest, what IS your DBL_MAX?

[iweindesmedt]

printf("%g", DBL_MAX); -> 3.40282e+38
FYI, with LDBL_MAX, it compiles too (can't get it to print though, guess the version of printf doesn't support %Le)

[DaveGamble]

Ok, so, you have a non IEEE754-compliant floating point implementation.
What it's complaining about is the 1e60 test which is used to ensure safety when printing huge integers. That number doesn't really pertain to anything in <float.h>, it pertains to ensuring that the number of digits that will be printed doesn't exceed the preallocated buffer size. A proper fix for this involves replacing sprintf with a custom printer, although that feels somewhat overkill.
Perhaps a good fix might be #if (DBL_MAX>1e60) around part of that test...?
Anyone else have any thoughts on this?

[FSMaxB]

Here it is suggested to use a long double literal for the 1e60, namely 1e60L. @iweindesmedt does that fix the overflow?

[iweindesmedt]

yes it does, good catch

[DaveGamble]

This is not a great change for the master branch. 1e60L is, as you say, a long double, the comparison against which requires a lot of legwork on the FPU (specifically an upcast to long double of the other value). This change worsens performance for JSON print for everyone, whilst fixing a bug for one platform with a non IEEE754 compliant floating point implementation.

[FSMaxB]

I reverted the commit. This should be easy enough to fix by hand if needed.