Re: [ANN] Lua 5.3.0 (work1) now available

[Jay Carlson <nop@...>]

On Jul 10, 2013, at 1:54 PM, Todd Coram wrote:

> On Wed, Jul 10, 2013, at 01:07 PM, Jay Carlson wrote:
>> Yeah. But for many protocols the only things which get that large are lengths, and x86_64 implementations can't address that much memory. 64-bit ARM has that architected tag mode, so they hit the address space wall at ~2^55.
> 
> Not to be pedantic, but when protocol specifies 64 bit ints, it is
> expected to handle 64 bit ints. If someone decides to pack extra
> meta-information into the upper bits of a 64 bit numbers, my Lua code
> shouldn't munge it.

Yes, this is the right thing. 

> A few months ago I released a BSON parser in pure Lua and was questioned
> by the BSON folk whether I truly supported int64 ... well I don't :-(

My question (usually) is, "what are the consequences of programmer error?" In a generic protocol library I think I would assert() if I could not represent a number precisely[1], since my program is very likely to produce incorrect results; the only question is at what time this will be noticed. There's a case where my program won't be using a field and hence won't be affected by that field containing 2^54+1, but the fact that a field will be unused sounds notable enough it may make sense to tell the library not to bother with it.

If Lua is to have non-signalling, wrapping integer overflow, I *think* I'd rather have the ints be unsigned, because the consequences of unexpected high->low seem slightly better than unexpected high->negative. OTOH negative numbers may be caught by assert()s elsewhere quickly. Multiplying two too-large numbers gets you a positive number a significant percent of the time in either case.

Jay

[1]: Uh, ignore my XML-RPC binding, which just ignores even non-integer integers. I was young and naive. And XML-RPC was internally contradictory, so you couldn't actually conform to it anyway...[more excuses deleted]