[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Features you would like to see
- From: Duck <duck@...>
- Date: Mon, 20 Aug 2007 08:29:33 +1000 (EST)
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"
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,
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.