[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: problem with string.format %d and very large integers
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Thu, 04 Aug 2011 13:11:47 +0200
On 04/08/2011 11.18, Dirk Laurie wrote:
On Thu, Aug 04, 2011 at 10:32:51AM +0200, liam mail wrote:
On 4 August 2011 07:43, Dirk Laurie<firstname.lastname@example.org<mailto:email@example.com>> wrote:
The real story is: "Lua has no integer type, as it does not need it.
… a Lua number can represent any long integer without rounding problems."
(PiL, §2.3). Sounds good to me.
I think you are looking at the first edition, in the second edition this
Yes, I copied-and-pasted from a window. The second edition says "32-bit
integer". The rest of my post makes clear that I was talking about that.
Added to that Lua 5.2 does in fact have an int type.
Please elaborate, giving a cut-and-paste of an interactive session and/or
a quote from the reference manual and/or an excerpt from the beta source
There are times where 4Gb are a real limit:
-- test to see if Lua can seek on a very huge file (>4Gb)
local fname = [[c:\lua-seek-test.dat]]
local fh = assert( io.open( fname, 'w+b' ) )
local n = 2^32 + 4
local pos = assert( fh:seek( 'set', n ) )
print( "New position at " .. pos .. " bytes from the beginning of the
On my system with 5.1.4 and 5.2 this creates a file of 4 bytes instead
of more than 4Gb.
Moreover, if you make n = 2^31 + 4, you get a nasty error, because seek
wraps it internally to a negative integer!
On todays' systems a 4Gb file is not too uncommon (a DVD ISO image
anyone?). Lua should be able to cope with those, IMO.
So, as I stated in another branch of this thread, this is a real problem
and programmers should have better info from the reference on the subject.
And the problem could be worse on machines with smaller int widths
(embedded systems?) - could 2^16 + 4 be wrapped on those machines?.