illegal seek

Discussion in 'C Programming' started by smarty, May 14, 2008.

  1. smarty

    smarty Guest

    this code gives an "illegal seek error" on close() call
    what is this error and when does it come?

    main()
    {
    int fd,num;
    char buf[150];
    fd = open ("123.c",O_RDWR);
    if(fd!=-1)
    {

    printf("a file with fd=%d is opened\n",fd);
    num=read(fd,buf,150);
    printf("num=%d\nREAD:%s",num,buf);
    perror("READ");
    close(fd);
    perror("CLOSE");
    }
    }
     
    smarty, May 14, 2008
    #1
    1. Advertising

  2. In article <>,
    smarty <> wrote:
    >this code gives an "illegal seek error" on close() call
    >what is this error and when does it come?


    Your code contains several errors, notably printing a potentially
    unterminated string from buf.

    But the particular problem you are asking about seems to be that
    Linux's perror() often changes errno. I don't think this is legal,
    but I don't have the standard to hand.

    -- Richard
    --
    :wq
     
    Richard Tobin, May 14, 2008
    #2
    1. Advertising

  3. >
    > But the particular problem you are asking about seems to be that
    > Linux's perror() often changes errno. I don't think this is legal,
    > but I don't have the standard to hand.


    Well, a standard library function may set errno to a non-zero
    function, unless
    the use of errno is documented in the standard (even if there was no
    error).
    The use of errno in perror() is documented in the standard as using
    its
    value.

    By the way, the read/open/close functions are not standard library
    functions.
    So nothing is known about them. I don't quite remember the posix
    specifications,
    but I am not sure if errno can put to a positive value on success.
    The return value of these functions might better indicate the error
    condition.
    The standard fopen/fread/fclose functions might equally well do the
    task, I'd think. Then you have ferror, too.
    Putting errno=0 before a standard library, that has a documented use
    of
    errno, and reading errno then seems to me legal, too.

    Szabolcs
     
    Szabolcs Borsanyi, May 14, 2008
    #3
  4. (Richard Tobin) writes:

    > In article <>,
    > smarty <> wrote:
    >>this code gives an "illegal seek error" on close() call
    >>what is this error and when does it come?

    >
    > Your code contains several errors, notably printing a potentially
    > unterminated string from buf.
    >
    > But the particular problem you are asking about seems to be that
    > Linux's perror() often changes errno. I don't think this is legal,
    > but I don't have the standard to hand.


    Hmmm... The standard says:

    "The value of errno may be set to nonzero by a library function call
    whether or not there is an error, provided the use of errno is not
    documented in the description of the function in this International
    Standard."

    perror "documents the use of errno" so it seems it is not permitted to
    change it. Of course, if the intent of that phrase it to permit
    functions to change errno provided they are not documented as
    *setting* it in some specific way, then perror *is* allowed to set it
    nonzero. But then, why use the obviously broad phrase "use of"?

    In practise, it hardly matters. One should only rely on the value
    immediately following a function call that has failed in a way that
    documents the setting of errno and this is the problem the OP is
    having. Even if perror stuck to the letter of the standard, both the
    printf and the close call can make it nonzero (even if there is no
    error).

    --
    Ben.
     
    Ben Bacarisse, May 14, 2008
    #4
  5. In article <>,
    Szabolcs Borsanyi <-heidelberg.de> wrote:

    >By the way, the read/open/close functions are not standard library
    >functions.
    >So nothing is known about them. I don't quite remember the posix
    >specifications,
    >but I am not sure if errno can put to a positive value on success.


    The use of those functions is irrelevant to the perror() problem.
    The following program exhibits the same behavious on Linux:

    #include <stdio.h>

    int main(void)
    {
    perror("one");
    perror("two");
    return 0;
    }

    When I run it here it prints

    one: Success
    two: Illegal seek

    -- Richard
    --
    :wq
     
    Richard Tobin, May 14, 2008
    #5
  6. In article <>,
    CBFalconer <> wrote:
    >Who knows. There are no such functions as 'open', 'read', 'close'
    >in standard C.


    As it turns out, it's nothing to do with those functions.

    -- Richard
    --
    :wq
     
    Richard Tobin, May 14, 2008
    #6
  7. "smarty" <> schrieb im Newsbeitrag
    news:...
    > this code gives an "illegal seek error" on close() call
    > what is this error and when does it come?
    >
    > main()
    > {
    > int fd,num;
    > char buf[150];
    > fd = open ("123.c",O_RDWR);
    > if(fd!=-1)
    > {
    >
    > printf("a file with fd=%d is opened\n",fd);
    > num=read(fd,buf,150);
    > printf("num=%d\nREAD:%s",num,buf);
    > perror("READ");
    > close(fd);
    > perror("CLOSE");
    > }
    > }

    close() sets errno if (and only if) it fails, which it indicates by
    returning -1.
    printf() returns a negative value on failure.
    Only use perror() directly after a failed function call that is documented
    to set errno on failure or set errno to 0 prior to calling that function.

    Bye, Jojo
     
    Joachim Schmitz, May 14, 2008
    #7
  8. CBFalconer <> writes:
    > smarty wrote:
    >>
    >> this code gives an "illegal seek error" on close() call
    >> what is this error and when does it come?
    >>
    >> main()
    >> {
    >> int fd,num;
    >> char buf[150];
    >> fd = open ("123.c",O_RDWR);
    >> if(fd!=-1)
    >> {
    >>
    >> printf("a file with fd=%d is opened\n",fd);
    >> num=read(fd,buf,150);
    >> printf("num=%d\nREAD:%s",num,buf);
    >> perror("READ");
    >> close(fd);
    >> perror("CLOSE");
    >> }
    >> }

    >
    > Who knows. There are no such functions as 'open', 'read', 'close'
    > in standard C. Look up, and use, fopen and fclose, and check the
    > various standard library calls for means of reading numbers.


    Those are POSIX functions. The OP might well have a good reason to
    use them instead of the C standard functions fopen, fread, and fclose
    (the POSIX functions provide some features that the standard C
    functions don't). The quoted program doesn't demonstrate any such
    reason, but it's obviously just a sample.

    But yes, it's generally better to use the standard C I/O functions
    *unless* you have a specific reason to use the POSIX functions and pay
    the price of losing some portability.

    (Incidentally, the program has nothing to do with reading numbers; num
    is the number of bytes read.)

    Some incidental advice for the original poster:

    Write "int main(void)" rather than "main()".

    Adding a blank after each comma, after the "if" keyword, and before
    and after each binary operator, aids readability.

    Since main returns an int, it should do so: add "return 0;" before the
    closing brace. There are circumstances in which this is not necessary
    (if you're using a C99 implementation, or if you don't care about the
    status returned to the host environment), but it never hurts, and it's
    a good habit.

    And, of course, you should examine the value of errno only after you
    know a function has failed (but check the function's documentation to
    find out whether it even sets errno).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 14, 2008
    #8
  9. On 14 May 2008 at 16:39, CBFalconer wrote:
    > The following is a legal definition of close:
    >
    > int close(int parm) {
    > if (-1 == parm) parm++;
    > return parm;
    > }


    Wrong. It fails to meet the specification for close():

    "The close() function shall deallocate the file descriptor indicated
    by fildes. To deallocate means to make the file descriptor available for
    return by subsequent calls to open() or other functions that allocate
    file descriptors. All outstanding record locks owned by the process on
    the file associated with the file descriptor shall be removed (that is,
    unlocked)."
     
    Antoninus Twink, May 15, 2008
    #9
  10. Antoninus Twink wrote:
    > On 14 May 2008 at 16:39, CBFalconer wrote:
    >> The following is a legal definition of close:
    >>
    >> int close(int parm) {
    >> if (-1 == parm) parm++;
    >> return parm;
    >> }

    >
    > Wrong. It fails to meet the specification for close():
    >
    > "The close() function shall deallocate the file descriptor indicated
    > by fildes. To deallocate means to make the file descriptor available
    > for return by subsequent calls to open() or other functions that
    > allocate file descriptors. All outstanding record locks owned by the
    > process on the file associated with the file descriptor shall be
    > removed (that is, unlocked)."

    Guess you missed his point: close() is not in the C-Standard, hence there is
    no specification.
    Chuck simply ignores that close() exists in POSIX and is available to the
    vast majority of implementations. He also ignored the fact that the OP did
    use close() and that the most likely reason is that this is because it is
    provided by his implementation.

    Bye, Jojo
     
    Joachim Schmitz, May 16, 2008
    #10
  11. On May 16, 7:39 am, "Joachim Schmitz" <>
    wrote:
    > Antoninus Twink wrote:
    > > On 14 May 2008 at 16:39, CBFalconer wrote:
    > >> The following is a legal definition of close:

    >
    > >>    int close(int parm) {
    > >>       if (-1 == parm) parm++;
    > >>       return parm;
    > >>    }

    >
    > > Wrong. It fails to meet the specification for close():

    >
    > > "The close() function shall deallocate the file descriptor indicated
    > > by fildes. To deallocate means to make the file descriptor available
    > > for return by subsequent calls to open() or other functions that
    > > allocate file descriptors. All outstanding record locks owned by the
    > > process on the file associated with the file descriptor shall be
    > > removed (that is, unlocked)."

    >
    > Guess you missed his point: close() is not in the C-Standard, hence there is
    > no specification.
    > Chuck simply ignores that close() exists in POSIX and is available to the
    > vast majority of implementations.


    but not all. Since when was Posix on-topic to comp.lang.c

    > He also ignored the fact that the OP did
    > use close() and that the most likely reason is that this is because it is
    > provided by his implementation.


    I'm pretty sure I've created a function called close() that
    didn't match the Posix spec. (I'll not argue it was a
    really good idea)

    --
    Nick Keighley
     
    Nick Keighley, May 16, 2008
    #11
  12. On 16 May 2008 at 10:25, CBFalconer wrote:
    > Of course the Twink-troll also snipped my explanation, which
    > follows below:


    Indeed I did. Because it was utter bullshit. It was an expression of
    your opinion, which I violently disagree with, and I don't think it is
    worthy of a reply. You clearly never get bored of endless rants about
    topicality, but I'm no longer rising to the bait.

    Watch: I'm snipping it again.

    [snip]

    > which is part of the trolls standard mechanism, aiming to disturb
    > the normal operation of the newsgroup.


    Of course, replying to spam doesn't disturb the normal operation of the
    newsgroup in the slightest. Neither does your continual attempts to
    drive away new participants in the group by continually spewing out your
    tedious views on topicality. And neither does the stream of
    embarrassingly wrong answers you provide to questions.

    > I see no reason to ever use open, close and read, when fopen, fclose
    > and fread are available everywhere, and portable.


    Of course you don't. You have no interest in any program more
    complicated than a solution to one of the exercises in K&R. You have an
    arrogant disdain for people who dirty their hands with real-world
    programming, when they might come across good reasons to use open, close
    and read. Here are the first few that spring to mind:

    * to be able to work with file permissions and ownership
    * getting file information with fstat (e.g. the size of a file)
    * locking files with fcntl or flock
    * getting file change notifications with fcntl
    * to be able to send ioctls to devices
     
    Antoninus Twink, May 16, 2008
    #12
  13. In article <>,
    Antoninus Twink <> wrote:
    >On 16 May 2008 at 10:25, CBFalconer wrote:


    >> I see no reason to ever use open, close and read, when fopen, fclose
    >> and fread are available everywhere, and portable.


    >Here are the first few that spring to mind:


    >* to be able to work with file permissions and ownership
    >* getting file information with fstat (e.g. the size of a file)
    >* locking files with fcntl or flock
    >* getting file change notifications with fcntl
    >* to be able to send ioctls to devices


    Those all involve extensions beyond the perview of C itself, and
    are best discussed in a newsgroup that deals with the scope of the
    extensions required (e.g., POSIX is going to have different behaviours
    than Linux or MS Windows.)

    In every extension I can currently think of that supports
    the operations listed, open(), close() and read() are unnecessary
    for any of the listed operations: those operations work on file
    descriptors, and one can determine a FILE's file descriptor using
    the fileno() extension upon a file that one has fopen()'d.
    And if there are OS's that support file descriptors but do not
    offer fileno() but still offer the listed operations, then such
    OSs would certainly not be operating in any standardized way, which
    would make it even more important to discuss the details in
    an appropriate newsgroup rather than here.

    --
    "This quitting thing, it's a hard habit to break once you start."
    -- Walter Matthau
     
    Walter Roberson, May 16, 2008
    #13
  14. On 16 May 2008 at 18:00, Walter Roberson wrote:
    > In every extension I can currently think of that supports
    > the operations listed, open(), close() and read() are unnecessary
    > for any of the listed operations: those operations work on file
    > descriptors, and one can determine a FILE's file descriptor using
    > the fileno() extension upon a file that one has fopen()'d.


    Are you saying that to create a file with 640 permissions you would use
    fopen+fileno+fcntl rather than just open()?
     
    Antoninus Twink, May 16, 2008
    #14
  15. In article <>,
    Antoninus Twink <> wrote:
    >On 16 May 2008 at 18:00, Walter Roberson wrote:
    >> In every extension I can currently think of that supports
    >> the operations listed, open(), close() and read() are unnecessary
    >> for any of the listed operations: those operations work on file
    >> descriptors, and one can determine a FILE's file descriptor using
    >> the fileno() extension upon a file that one has fopen()'d.


    >Are you saying that to create a file with 640 permissions you would use
    >fopen+fileno+fcntl rather than just open()?


    fopen() followed by the fchmod() extension would do fine in situations
    where race conditions were not an issue. (Your listed operation
    was "work with" permissions, not the more difficult task of
    handling files securely.)
    --
    "Pray do not take the pains / To set me right. /
    In vain my faults ye quote; / I wrote as others wrote /
    On Sunium's hight." -- Walter Savage Landor
     
    Walter Roberson, May 16, 2008
    #15
  16. smarty

    jacob navia Guest

    Walter Roberson wrote:
    > In article <>,
    > Antoninus Twink <> wrote:
    >> On 16 May 2008 at 10:25, CBFalconer wrote:

    >
    >>> I see no reason to ever use open, close and read, when fopen, fclose
    >>> and fread are available everywhere, and portable.

    >
    >> Here are the first few that spring to mind:

    >
    >> * to be able to work with file permissions and ownership
    >> * getting file information with fstat (e.g. the size of a file)
    >> * locking files with fcntl or flock
    >> * getting file change notifications with fcntl
    >> * to be able to send ioctls to devices

    >
    > Those all involve extensions beyond the perview of C itself, and
    > are best discussed in a newsgroup that deals with the scope of the
    > extensions required (e.g., POSIX is going to have different behaviours
    > than Linux or MS Windows.)
    >
    > In every extension I can currently think of that supports
    > the operations listed, open(), close() and read() are unnecessary
    > for any of the listed operations: those operations work on file
    > descriptors, and one can determine a FILE's file descriptor using
    > the fileno() extension upon a file that one has fopen()'d.
    > And if there are OS's that support file descriptors but do not
    > offer fileno() but still offer the listed operations, then such
    > OSs would certainly not be operating in any standardized way, which
    > would make it even more important to discuss the details in
    > an appropriate newsgroup rather than here.
    >



    You snipped one part of the answer of Mr Twink:

    You have no interest in any program more
    complicated than a solution to one of the exercises in K&R. You have an
    arrogant disdain for people who dirty their hands with real-world
    programming, when they might come across good reasons to use open, close
    and read.

    Why would you need to use fileno each time when you just
    use open/close etc and be done with it?

    You gave no valid reason.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, May 16, 2008
    #16
  17. jacob navia <> writes:
    [...]
    > Why would you need to use fileno each time when you just
    > use open/close etc and be done with it?
    >
    > You gave no valid reason.


    I'm sure there are plenty of valid reasons to use open/close rather
    than fileno.

    comp.unix.programmer would be a great place to discuss those reasons
    (if they're not already thoroughly covered in the FAQ).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 16, 2008
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    4
    Views:
    1,084
  2. Dave Saville

    illegal seek

    Dave Saville, Sep 8, 2003, in forum: Perl Misc
    Replies:
    21
    Views:
    291
    Alan J. Flavell
    Sep 17, 2003
  3. Illegal Seek - Any Hints

    , Apr 4, 2005, in forum: Perl Misc
    Replies:
    3
    Views:
    143
  4. Eric

    Illegal seek

    Eric, Apr 13, 2007, in forum: Perl Misc
    Replies:
    7
    Views:
    476
  5. Replies:
    3
    Views:
    131
    Andreas Perstinger
    May 14, 2013
Loading...

Share This Page