problem with lseek system call on unix

This is a discussion on problem with lseek system call on unix within the C Programming forums, part of the General Programming Boards category; Hi, Something weird is happenning with lseek. I've been using it heavily for the past 3 months on a project ...

  1. #1
    Registered User
    Join Date
    Jun 2003
    Posts
    1

    problem with lseek system call on unix

    Hi,

    Something weird is happenning with lseek. I've been using it heavily
    for the past 3 months on a project I'm working on, and now all of a
    sudden it's returning an error with no apparent reason:
    For example: it gives me and error when I move lseek to the 65*512th
    byte in a file that has far more than that many bytes. And no matter
    how big the file is, it is the error is always on the 65*512th byte
    lseek.

    Anyone has a clue as to what might be wrong? Or at least any general
    suggestions as to why lseek might be returning an error when its
    arguments are reasonable.

    Thanks alot,
    Khaled

  2. #2
    Been here, done that.
    Join Date
    May 2003
    Posts
    1,157
    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.
    Last edited by WaltP; 06-02-2003 at 09:09 PM.
    Definition: Politics -- Latin, from
    poly meaning many and
    tics meaning blood sucking parasites
    -- Tom Smothers

  3. #3
    Been here, done that.
    Join Date
    May 2003
    Posts
    1,157
    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.
    Definition: Politics -- Latin, from
    poly meaning many and
    tics meaning blood sucking parasites
    -- Tom Smothers

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 6
    Last Post: 07-21-2008, 03:10 AM
  2. nanosleep() -system call does some confusing things
    By jtk in forum Linux Programming
    Replies: 5
    Last Post: 08-30-2007, 04:15 AM
  3. temperature sensors
    By danko in forum C Programming
    Replies: 22
    Last Post: 07-10-2007, 07:26 PM
  4. What system call use the CreateThread Function of borland?
    By amfm0777 in forum Windows Programming
    Replies: 2
    Last Post: 06-20-2007, 05:41 AM
  5. System call to call another C file from Existing C File
    By simly01 in forum C++ Programming
    Replies: 2
    Last Post: 07-31-2002, 01:29 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21