Mail Archives: djgpp/1997/07/02/15:59:45
On Wed, 2 Jul 1997 17:41:12 +0300 (IDT), Eli Zaretskii wrote:
> On Wed, 2 Jul 1997, Michael Mauch wrote:
>
> > So, given that the DJGPP implementation of binary streams does "not
> > meaningfully support fseek", shouldn't fseek() then always fail for this
> > "request that cannot be satisfied", i.e. using SEEK_END on binary
> > streams?
>
> If I remember correctly your original posting, you tried to move from the
> end of the file by more than the file size?
Yes.
> If so, why is it a problem
> when you get moved to the beginning of the file?
Because I tried to move _before_ the beginning of the file, and this
request can't be satisfied by fseek(), so I think it should report an
error and not silently move me to a place where I didn't want to go,
IMHO. OTOH, if this is what other compilers do (and other people expect
fseek() to do), then my idea to redesign fseek() is probably a bad idea.
> I'm not aware of any problems with `fseek' in its current implementation,
> neither with binary nor with text files. It is true that ANSI doesn't
> require much from a compliant library as far as `fseek' is concerned, but
> DJGPP v2.01 goes out of its way to make its `fseek' support every wild
> request. (In fact, the entire buffered I/O machinery was redesigned for
> DJGPP 2.01 with the sole purpose of making `fseek' and `ftell' work
> better.)
Yes, I think it's best to keep in mind (*) that the behaviour of fseek()
is not completely ANSI-standardized and DJGPP supports one commonly used
practice but not the other, because there's no way to support both of
them.
On the INFO-ZIP list, somebody told that my test program returned 0 when
compiled with Watcom 7 for 16bit DOS and -1 with Watcom 9.5c for OS/2
(32 bit). The same is true with Borland C++ 4.52: the 16-bit version
gives 0, the Win32-console version gives -1. So there's really no way to
rely on a standard behaviour.
Moreover, my test program (and the InfoZIP people's Zip 2.2m beta)
probably could use ftell() after fseek(,,SEEK_END) to check where the
fseek() moved the file pointer - or ask ftell() before fseek(), to check
if the file is large enough.
Ok, it was all my (or InfoZIP's) fault.
> `lseek' in DJGPP just calls the relevant DOS function. Only if DOS
> returns an error indicator, does `lseek' return -1. I guess in your case
> the file pointer gets moved to the beginning of the file, which isn't so
> unreasonable, given that this is what DOS does.
DJGPP's lseek() happily moves the file pointer to a negative value, e.g.
-3651. From that imaginary position you can seek to the start of the
file again with lseek(fd,+3651,SEEK_CUR). Probably that's also one of
the expected behaviours of some or many lseek() implementations. The
same holds true for fseek().
Regards...
Michael
*: Maybe it's possible to include such a hint (**) in the libc.info
file, for those of us who are suffering from Alzheimer's disease and
can't keep in mind all the standards and not-standards.
**: Suggestion:
When using SEEK_END, be aware that the ANSI-C standard does not define a
specific behaviour if you try to move the file pointer before the
beginning of the file. Some implementations of fseek() return an error
(i.e. nonzero) in this situation, others and DJGPP don't. The DJGPP
implementation moves the file pointer to an imaginary negative position
and returns 0. From that position, you can fseek() forward to any
position you like. For portable programs, it's a good idea to use
ftell() after fseek() to check where the file pointer really has been
set.
--
PGP key (0x013CB889) available at public key servers. PGP mail welcome.
PGP fingerprint: 83 D1 C4 76 0A F5 35 C6 C6 C4 C8 73 1B 45 E9 D5
- Raw text -