Re: More thoughts on Lua 5.2

[Duck <duck@...>]

>Well, you can: you use fseek(..., SEEK_CUR); 
>iteratively and keep track of the pointer yourself.

Hmmm. Can you? I can't figure out how to be able to do this using a 
standard build of Lua:

> f,e,n = io.fopen('my3gbfile.raw')
> = f,e,n
> nil     my3gbfile.raw: File too large    27

Now, AFAIK you can open up and manually move around in 64-bit-sized files 
using 32-bit libraries (and offsets) if you use O_LARGEFILE when calling 
open(), except that we aren't using OS-level I/O, were using ANSI-C-level 
FILE *s, so we're calling fopen instead().

So, you could recompile everything with _FILE_OFFSET_BITS=64, but...

...is this supported? Was Lua built with it in mind? Can I expect it to 
work or do I need to reinvent my own tests and regression tests every time 
I update my Lua build? What other limits on my ability to access regular 
files in my filing system might exist in Lua's standard library code? What 
things won't work in the real world? 

(Path length is another problem for the pure ANSI-CD-based io library, 
seeing as it doesn't even admit of paths. Even lfs is somewhat hamstrung 
in this regard, with built-in hard wired string length limits such as 
256. Sure, you can re#define some of them, but to what? And why? And who 
has tested that before?)

My point was not so much that I wanted a way to access files bigger than 
2GB (or to make use of functions relating to the hierarchical file system 
which almost all Lua platforms support, or to use sockets), but that I was 
suggesting it might be great to have all these things available _as 
optional libraries that are provided out of PUC-Rio as part of the "this 
fits together as a whole" distro that is Lua_.

I trust LuaSocket and use it happily. But I'd be even happier if it were 
currently at LuaSocket 5.1.3, delivered as part of Lua 5.1.3. Same for 
lfs, which is a separate project, with a different outlook to Lua itself 
on what portability means. (lfs works on Windows, but it isn't really 
portable between Linux and Windows. Indeed, lfs is UNIX/Linux specific, 
but can be compiled "in part" so that a useful subset of it happens to 
work on Windows.)

Several respondents have explained to me how I can solve my >2GB 
"problem", mostly by hacking the Lua sources. But original suggestion was 
of a few additional libs which would help to create a (more useable and 
attractive) Lua distro in which that commonly-needed or expected hacks of 
that sort would simply not be necessary.