3 replies to this topic

[Orwell]

Hi everybody. I didn't want to post this in the bug section straight away because it's always more likely that I'm missing something here. It's best to think this through with a couple of people first.

So, when using 'string.format' with '%u', you'd expect a number to be formatted as an unsigned integer, as documented here, but this is what I get while using it:

lua> string.format("%d, %i, %u", -100,-100,-100)
-100, -100, -100

Expected output would be:

-100, -100, 4294967196

Anyone has thoughts on this? I suppose that if this is indeed a bug, it would be in LuaJ.

[ChunLing]

Lua numbers are never integers, signed or unsigned. They are always floating point. We can use them like integers for most purposes, but not for roll-over.

Which is to say, emulating this behavior is an "addon", the absence could be considered a bug or simply a lack of support for a defined feature of the language.

Edited by ChunLing, 02 January 2013 - 03:00 AM.

[Orwell]

ChunLing, on 02 January 2013 - 02:58 AM, said:

Lua numbers are never integers, signed or unsigned. They are always floating point. We can use them like integers for most purposes, but not for roll-over.

Which is to say, emulating this behavior is an "addon", the absence could be considered a bug or simply a lack of support for a defined feature of the language.

I know that, it's a simple conversion. But I'm rather curious at how this conversion could fail... Whether it's a cast Java side, or an actual calculation, it seems to be flawed. It might be an addon as you call it, but it's indeed still a defined feature of a standard library. So if it's indeed failing to behave like expected, it could be considered a bug IMO.

[ChunLing]

Hmmm...yeah. It's supposed to work, and it doesn't. Not the first (or worse) bug in LuaJ. When are we dumping that for something else?