-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
JSON integer mangling #807
Comments
%g would round off to five places since its compact float, so clearly we'd have a problem with large numbers. But wouldn't changing the flag to %f solve the issue (unless its greater than 100,000,000,000,000 going by the docs)? @nnposter |
Using %f would not work either:
|
Ah, forgot about the extra decimals that come with %f. The fix must work, don't see any side effects (at least none are mentioned in the docs) associated with them :) |
Using tostring would be better in most cases, though it does introduce a ".0" at the end if the number is not a Lua Integer. Still, this removes control of the formatting a bit from the JSON library and puts it back in control of the calling script, which would be responsible for calling math.tointeger if necessary. |
Here is an overview of the effect:
IMHO @dmiller-nmap I understand and agree with what you are saying but I am not sure whether you are agreeing with the proposed change or you have concerns over it. |
Function
json.generate
is usingstring.format("%g", obj)
to convert numbers to strings. This has an undesired effect of mangling longer integers as follows:String
str
is now{"session": 1.68412e+009}
.I wonder if it would be more appropriate to use
tostring(obj)
, which does not have this side-effect.Digging into the history, the "%g" conversion has been there since the initial
json.lua
commit by David in 2010 (r16896).The text was updated successfully, but these errors were encountered: