Mail Archives: djgpp-workers/2000/12/13/06:23:33
On Tue, 12 Dec 2000, Peter J. Farley III wrote:
> I researched the question of a zero length to int21/5C. RBIL is silent
> on the allowed values. I will have to try setting the current position
> past EOF and then try locking to check the negative case, and setting
> it at EOF and try locking to check the zero case.
You could make it part of the test program; that way, if something
changes in some future versions of DOS/Windows, we'd know.
> >> + len = filelength(fd) - cur_pos;
> >> + /* This should probably be an error. */
> >> + if (len <= 0L)
> >> + len = 1L;
> >
> >Does filelength in the current CVS support FAT32?
>
> I checked filelength, and it returns a long value. Here is the
> relevant code snippet in "src/libc/posix/sys/stat/filelen.c":
>
> /* The absolute byte offset returned in DX:AX is the file size. */
> retval = ( (long)regs.x.dx << 16 ) + regs.x.ax;
>
> It looks to me as if this code *will* return negative numbers, since it
> is not an unsigned long, when the current position has been set past
> 2^31-1. I think we will therefore get wrong negative answers for
> positive FAT32 offsets > 2^31-1 and < 2^32-2.
So I think it would be easier for you to dump filelength and use
llseek in all cases, including the FAT16 branch. In other words,
expand filelength's guts inline and replace lseek with llseek.
> len = (unsigned long)filelength(fd) - cur_pos;
I think this is unsafe because filelength uses lseek, which is
dangerous on FAT32 volumes.
- Raw text -