Change struct & sjson to use integers. This is slightly more complex #3222
Conversation
…ve to deal with Unsigned 32-bit integers (that aren't lua integers)
|
Color me skeptical about the use of More nit-picky: please use |
|
The use of double was deliberate as this function returns an integer that can be much larger than a 32 bit integer (which also be unsigned). The double can hold a 53 bit integer -- but it could be that we want this to return a I'll test it. And yes, I'll fix the INT_MIN/MAX case. |
|
Ah, I misread the diff in my skim, sorry... |
|
Fixed sjson as well for the gross effects. Still not sure whether it uses the right number of digits or not. |
pjsg
changed the title
app/modules/sjson.c
Outdated
| lua_pushlstring(data->L, start, end - start); | ||
| // See if there is any chance that this is an integer | ||
| #if LUA_VERSION_NUM >= 503 | ||
| char notint = 0; |
There was a problem hiding this comment.
As I discussed in #3213, the Lua 5.3 API already has a function lua_stringtonumber() which does all of this as a standard Lua API call. Why reimplement standard functionality?
There was a problem hiding this comment.
The short answer is that I did not know about this function....
There was a problem hiding this comment.
@pjsg TBH Philip, the only reason that I came across this was because of my work to harmonise the 5.1 and 5.3 APIs so that we don't need to have conditional LUA_VERSION_NUM variant code in our modules. In general Lua hides sub types in its exposed API, so there is no difference from an API perspective between the various function subtypes: they are all classed as function. Ditty short vs long strings, and Tables vs ROTables. The one exception is the handling of integer vs number subtypes as there is an lua_isinteger() call and variant get and put API calls. This one is a sensible extension one one that IMO is also worth back-porting into the Lua API. If I do this, then I will also remove this variant code as the 503 version will work fine with both versions.
There was a problem hiding this comment.
This case is ugly -- and made worse by the fact that the input buffer is not null terminated and I was nervous that the number parsing might fall off the end of the buffer... I suspect that it would never happen, but I prefer to err on the side of caution.
…odemcu#3222) * Change struct to use integers. This is slightly more complex as we have to deal with Unsigned 32-bit integers (that aren't lua integers) * Use int64 in struct rather than double. * Fix sjson to do the right things in LUA5.3 with integers and floats
Fixes #3217.
Make sure all boxes are checked (add x inside the brackets) when you submit your contribution, remove this sentence before doing so.
devbranch rather than formaster.docs/*.This is slightly more complex as we have to avoid casting to lua_Numbers if there a need to have integer values. We also need to deal with unsigned 32 bit integers that are not representable as a lua integer. However, this seems to work