Mail Archives: djgpp-workers/2002/06/16/11:11:47
Hello.
Martin Str|mberg wrote:
>
> According to Richard Dawe:
[snip]
> > represent in the positive portion of a long. 'ls' (IIRC which program)
> > from Fileutils has already been bitten by this bug.
>
> Yes. And I think the solution is llseek(). At least that was my idea
> when I wrote it.
Unfortunately it's not just lseek that can't cope properly with files bigger
than 2GB. The problem with 'ls' was that stat returns the file size member
which is a negative number (> 2GB - 1B). So *stat need to be fixed too.
See a mail to djgpp-workers by Paul Eggert "Re: GNU ls bug on DJGPP with large
files". This is dated Wed, 8 Aug 2001 10:37:29 -0700 (PDT) in my mail archive.
> > * It won't let you seek beyond the maximum offset [that you can represent
> > in the positive portion of off_t]. This is where the file manipulation
> > files return -1 and errno == EOVERFLOW.
>
> Then change lseek() to guard for this. (Use llseek() and some math to
> check for "overflow".)
>
> Or perhaps this is what you intend to do?
Yes, that's one of the functions that needs fixing.
LFS requires that file functions return -1 and EOVERFLOW, if they would go
past the maximum offset representable by an off_t. One benefit of this is to
catch problems in programs that have not been written with the expectation
that the offset could be negative. (I think that's a reasonable expectation!)
For instance, consider the following code:
int some_file_descriptor;
off_t o;
...
o = lseek(some_file_descriptor, 1234, SEEK_CUR);
if (o < 0)
perror("bleurgh"), exit(EXIT_FAILURE);
...
Is that code valid? It looks reasonable, if you expect file offsets to always
be positive. But it will break with DJGPP CVS & large files. If you look at
the actual definition of lseek in the Austin draft 7, it does say that only a
return value of -1 indicates an error. So the code, though it looks
reasonable, is broken.
Sure, you can work around the "negative offsets are really postive offsets >=
2GB" problem. But you have to patch every single application that might hit
this problem. Isn't it more sensible to support a larger off_t [in a
backwardly- and binarily-compatible way], to avoid having to hack every
program? With LFS support, you just define _LARGEFILE_SOURCE and recompile.
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -