regarding lseek and fread

Discussion in 'C Programming' started by venkat, May 27, 2007.

  1. venkat

    venkat Guest

    Hi,

    I am learing Unix internals. I have come across a problem where
    i am not able to understand what is happening. As i gone through the
    book i found that lseek will give the physical descriptor and ftell
    will give about logical descriptor, but when i read the text using
    fread the ftell and lseek should give diffrent values. but when new
    process comes into to existence ftell should use lseek value. but is
    not happening the output line given below and the code is given
    below.

    #include<stdio.h>
    #include <unistd.h>
    main()
    {
    FILE *fp;
    char buf[10];
    int pid , dip;

    fp = fopen("vikas", "r");
    pid = fork();
    if (pid == 0) {
    printf("in child before read fseek is %d , lseek is %d \n",
    ftell(fp), lseek(fp->_file ,0, 1));
    fread(buf, sizeof buf , 1, fp);
    buf[10] ='\0';
    printf("after child read file pointer ftell is %d, lseek is %d
    %s\n", ftell(fp), lseek(fp->_file ,0, 1)
    , buf);
    sleep(5);
    fread(buf, sizeof buf, 1, fp);
    buf[10] = '\0';
    printf("after child 2nd time read file pointer is %d , lseek is
    %d %s\n", ftell(fp), lseek(fp->_file, 0
    , 1), buf);
    }
    else {
    wait(0);
    printf("intially in parent file ponte %d, lseek is %d %s\n",
    ftell(fp), lseek(fp->_file, 0, 1), buf);
    fread(buf, sizeof buf, 1, fp);
    buf[10] ='\0';
    printf("after parent read file pointer is %d ,lseek is %d %s
    \n", ftell(fp), lseek(fp->_file, 0, 1), bu
    f);
    }
    }

    output is
    in child before read fseek is 0 , lseek is 0
    after child read file pointer ftell is 10, lseek is 4096 AAAAAAAAAA
    after child 2nd time read file pointer is 20 , lseek is 4096
    AAAAAAAAAA
    intially in parent file ponte 20, lseek is 20
    after parent read file pointer is 30 ,lseek is 4096 AAAAAAAAAA

    i am not able to undersand the parent portion. why the ftell is using
    20 as for a new process it should use lseek value, and how come the
    lseek value has been changed?.

    Appreciate your help in this read.

    Thanks,
    Venkat.
     
    venkat, May 27, 2007
    #1
    1. Advertising

  2. In article <>,
    venkat <> wrote:

    > I am learing Unix internals. I have come across a problem where
    >i am not able to understand what is happening. As i gone through the
    >book i found that lseek will give the physical descriptor and ftell
    >will give about logical descriptor,


    lseek() and fork() and unistd.h are not defined by the C language.
    You should ask your question in a newsgroup that deals with your
    OS internals.


    > printf("in child before read fseek is %d , lseek is %d \n",
    >ftell(fp), lseek(fp->_file ,0, 1));


    <OT>
    lseek is defined as returning off_t which might well not be
    an int (and usually is not), so using a %d format for the
    output of the result of lseek() is not correct.

    By the way, for portability you should not be assuming the
    existance of a _file member of the FILE structure. That's
    an implementation aspect that is subject to change. You should
    use the fileno() macro.

    But for the rest of your question, after making the above fixes,
    you need to consult a unix newsgroup.
    --
    There are some ideas so wrong that only a very intelligent person
    could believe in them. -- George Orwell
     
    Walter Roberson, May 27, 2007
    #2
    1. Advertising

  3. venkat wrote:
    > Hi,
    >
    > I am learing Unix internals. I have come across a problem where
    > i am not able to understand what is happening. As i gone through the
    > book i found that lseek will give the physical descriptor and ftell
    > will give about logical descriptor, but when i read the text using
    > fread the ftell and lseek should give diffrent values. but when new
    > process comes into to existence ftell should use lseek value.


    You have aseveral simple errors as far as the C programming language is
    concerned. ftell() returns a long and you incorrectly try to print that
    value with the designator "%d". In addition, you attempt illegally to
    buf[10] ='\0';
    but there is no such buf[10]. This should cause in segfault in most
    varieties of Unix. Further, you make no effor to check that "vikas" was
    successfully opened for read. You combine the incompatible errors of
    using an implicit int return type for main (allowed only before C99) and
    omitting the explicit return (or exit()) from main (allowed only in C99
    and later).

    As far as this newsgroup is concerned, the difference between lseek and
    ftell is simple: there is a standard C function called ftell, there is
    not such a standard C function called lseek. Since C I/O identifies
    streams through pointers-to-FILE and the most common definition of lseek
    (POSIX, but in the programmer's namespace in C, so it could be anything)
    identifies the stream with an integer "file descriptor", you have a big
    hint that lseek is not a standard C function. The fact that you need to
    include the non-standard <unistd.h> header is another big hint.
    Additionally, form(), wait(), and sleep() are not standard C functions.

    What this means is that you need to ask your question in a newsgroup
    where lseek is topical. That means one concerned with POSIX or some
    near-relative of Unix.



    > but is
    > not happening the output line given below and the code is given
    > below.
    >
    > #include<stdio.h>
    > #include <unistd.h>
    > main()
    > {
    > FILE *fp;
    > char buf[10];
    > int pid , dip;
    >
    > fp = fopen("vikas", "r");
    > pid = fork();
    > if (pid == 0) {
    > printf("in child before read fseek is %d , lseek is %d \n",
    > ftell(fp), lseek(fp->_file ,0, 1));
    > fread(buf, sizeof buf , 1, fp);
    > buf[10] ='\0';
    > printf("after child read file pointer ftell is %d, lseek is %d
    > %s\n", ftell(fp), lseek(fp->_file ,0, 1)
    > , buf);
    > sleep(5);
    > fread(buf, sizeof buf, 1, fp);
    > buf[10] = '\0';
    > printf("after child 2nd time read file pointer is %d , lseek is
    > %d %s\n", ftell(fp), lseek(fp->_file, 0
    > , 1), buf);
    > }
    > else {
    > wait(0);
    > printf("intially in parent file ponte %d, lseek is %d %s\n",
    > ftell(fp), lseek(fp->_file, 0, 1), buf);
    > fread(buf, sizeof buf, 1, fp);
    > buf[10] ='\0';
    > printf("after parent read file pointer is %d ,lseek is %d %s
    > \n", ftell(fp), lseek(fp->_file, 0, 1), bu
    > f);
    > }
    > }
    >
    > output is
    > in child before read fseek is 0 , lseek is 0
    > after child read file pointer ftell is 10, lseek is 4096 AAAAAAAAAA
    > after child 2nd time read file pointer is 20 , lseek is 4096
    > AAAAAAAAAA
    > intially in parent file ponte 20, lseek is 20
    > after parent read file pointer is 30 ,lseek is 4096 AAAAAAAAAA
    >
    > i am not able to undersand the parent portion. why the ftell is using
    > 20 as for a new process it should use lseek value, and how come the
    > lseek value has been changed?.
    >
    > Appreciate your help in this read.
    >
    > Thanks,
    > Venkat.
    >
     
    Martin Ambuhl, May 27, 2007
    #3
    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. Elephant

    Code for lseek

    Elephant, Jan 12, 2006, in forum: C Programming
    Replies:
    2
    Views:
    783
    Walter Roberson
    Jan 12, 2006
  2. golden

    lseek and write question

    golden, Nov 16, 2007, in forum: C++
    Replies:
    3
    Views:
    590
    James Kanze
    Nov 17, 2007
  3. Gordon Beaton
    Replies:
    3
    Views:
    1,364
  4. pavunkumar

    Lseek Error

    pavunkumar, Mar 31, 2009, in forum: C Programming
    Replies:
    2
    Views:
    483
    Rob Clarke
    Mar 31, 2009
  5. Replies:
    3
    Views:
    131
    Andreas Perstinger
    May 14, 2013
Loading...

Share This Page