Thread: problem with lseek system call on unix

The location you're looking for is byte 33280.

According to http://www.opengroup.org/onlinepubs/...s/types.h.html
lseek() returns a type of off_t which is defined as "signed integer types", therefore the max is 32767.

Try fseek() which used a long offset, and is standard C. lseek doesn't appear to be standard.

Originally posted by vVv
> lseek() returns a type of off_t which is defined as "signed integer types", therefore the max is 32767.

Complete bogus statement. These restrictions might apply to dead DOS systems, but there is not a single Unix system that doesn't have at least a default 32bit integer size.

> Try fseek() which used a long offset, and is standard C. lseek doesn't appear to be standard.

Complete bogus statement. There is nothing wrong with using ``non-standard'' code, and in fact it's mandatory to use lseek() if you are dealing with file descriptors. Apart from that, any system that provides lseek() is very likely to implement fseek() using lseek(), so any possible restrictions of lseek() are invariably inherited.
As Salem said, do this:

Code:

if (lseek(fd, offset, whence) == -1) {
    perror("lseek");
}

I apologize, I couldn't tell kheinz is on a Unix system. What gave you the clue? I can't tell which OS nor Compiler from his message.

I understand that "non-standard" code is allowed, I use it all the time. But if lseek() isn't working, fseek() might -- because they have different definitions. and is it not a fact that lseek() is not standard and fseek() is? That was not a reason for switching, simply a notational comment.

From the information supplied, I made an educated guess -- lseek() isn't working above a signed 16bit int value. Therefore I have not made a bogus statements. I do realize I could have said "therefore the max may be 32767" and that may ave been more appropriate.