 |
lua-l archive |
|
|
||
|
1. A compile-time directive to select support for 64-bit (or at least 52-bit/53-bit) file offsets in the IO library.
should be the default. on systems that doesn't support big offsets, a config.h define should fall back.
At the monent, the ANSI-based IO lib uses FILE* objects for files, and uses fseek() to navigate around in them. But fseek() takes a 'long' offset, not an 'off_t' one, so unless your longs are (or are forced to) 64 bits throughout, file sizes are limited to 31 bits.
2. Compile-time (or even run-time!) support for choosing 8-bit, 16-bit or 32-bit "chars" as the basis of strings.3. Standardised compile-time selection of a floating point "number" type with more than 64 bits of integer precision.
can't see any sane reason for these.
Go west from, say, California for a few thousand kilometres. See how your 8-bit chars burst at the seams as you travel :-)
In some environments, there are 16 bits (or 32 bits) in a character. Lua strings simply aren't compatible with these. 16-bit and 32-bit characters are much more graceful to use than any of the various multibyte encodings such as Shift-JIS and Big5. Under Windows, for instance, a lot of the NTAPI functions use _only_ 16-bit strings, and many of the Win32API functions appear in ...A() and ...W() flavours. (ASCII, for 8-bit, and Wide, for 16-bit, chars in strings). In Windows Mobile, there are only ...W() functions, since it's assumed you want to write and build your code to be able to run globally, including in Japan, Korea, Hong Kong SAR, PRC, etc.
Being able to choose native 16-bit (or even 32-bit) strings would be very handy, especially since converting ASCII strings to, say, Microsoft-style wide strings is trivial, but the other way round is clearly impossible without astonishing loss of precision! Being able to read in a string and to do pattern matching against, say, English strings in Chinese text, or vice-versa, or to do a straight string.find() of Chinglish or Englinese strings (a very common thing indeed) inside arbitrary text (e.g. a Windows registry dump -- try regedit /e filename) would be handy.
As for support for integers of more than 64 bits, well, 64 is the new 32 :-) Existing Lua numbers can handle more than 32 bits of integer precision, so that it is possible reliably to perform calculations on data from external binary structures which include 32-bit values, signed or unsigned. (And since Lua handles more than 33 bits of precision, signed and unsigned int32s can converted directly to numbers and then fearlessly mixed in add/subtract/compare operations. Very handy indeed.)
There is an increasing number of external binary file formats in which 64-bit integers are as common as (or have simply replaced) the 32-bit integers of the 1990s. (Win64 executables spring to mind.)
Off-the-shelf PCs with 4GB RAM are commonplace. Even here in Oz (not the cheapest place in the world for anything) you can get 2x2GB RAM sticks for just over US$200. You can already buy consumer hard disks with more than 2^32 sectors. Having 52/53 bits of precision via the 'double' format just isn't convenient enough when you have a mix of signed and unsigned 64-bit integers thrust at you all the time.
So just as Lua proudly provides integers which exceed 32 bits of precision on all sorts of platform (by standardising on 'double' as a number type), it ought these days to have a standardised alternative which can exceed 64 bits of precision.