open and read functions (can't make 'read' work..)

Discussion in 'C Programming' started by ferbar, Sep 24, 2005.

  1. ferbar

    ferbar Guest

    Hi all,

    I'm trying to read from the txt file 'ip.packets.2.txt' using the read
    function. It seems everything ok, but I get a -1 when executing

    >>bytesr = read(fdo1, bufread, 2);


    The 'open' function returns the file dsc 3. So this seems ok..

    Any idea what might be wrong?

    Thanks!

    FBM

    #define BUFSIZE 1024

    #include <fcntl.h>
    #include <sys/time.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <unistd.h>

    double now() {
    struct timeval t;
    gettimeofday(&t,NULL);
    return ((double)t.tv_sec + (double)t.tv_usec/1000000.0);
    }

    int main(int argc, char** argv) {
    int fdo1;
    double t;
    char * pathname;
    ssize_t bytesr;
    void * bufread;

    pathname = argv[1];
    fdo1 = open("C:/cygwin/home/Jeannie/workspace/hw2/ip.packets.2.txt",
    O_RDWR);
    t = now();
    bytesr = read(fdo1, bufread, 2);
    t = now() - t;
    printf("time %.3f\n", t);
    exit(0);
    }
     
    ferbar, Sep 24, 2005
    #1
    1. Advertising

  2. ferbar

    Jack Klein Guest

    On 24 Sep 2005 12:59:19 -0700, "ferbar" <> wrote in
    comp.lang.c:

    > Hi all,
    >
    > I'm trying to read from the txt file 'ip.packets.2.txt' using the read
    > function. It seems everything ok, but I get a -1 when executing


    Unfortunately there is no 'read' function in C. It is, as far as the
    C language and this newsgroup are concerned, a non-standard platform
    specific extension.

    > >>bytesr = read(fdo1, bufread, 2);

    >
    > The 'open' function returns the file dsc 3. So this seems ok..


    No 'open' function in C either.

    > Any idea what might be wrong?
    >
    > Thanks!
    >
    > FBM
    >
    > #define BUFSIZE 1024
    >
    > #include <fcntl.h>
    > #include <sys/time.h>
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <unistd.h>


    The headers <stdio.h> and <stdlib.h> are standard C, the other three
    are non-standard extensions and not discussed here.

    I won't go through your code and point out the rest of your functions
    that are non-standard and off-topic here. Since you posted through
    Google, there is no header information to provide insight on your
    system.

    > double now() {
    > struct timeval t;
    > gettimeofday(&t,NULL);
    > return ((double)t.tv_sec + (double)t.tv_usec/1000000.0);
    > }
    >
    > int main(int argc, char** argv) {
    > int fdo1;
    > double t;
    > char * pathname;
    > ssize_t bytesr;
    > void * bufread;


    The declaration above looks like it could very well cause a real
    problem. You have defined a pointer to void, but it is uninitialized.
    You have not defined any data for it to point to, nor have you set it
    to point to anything useful. Any use of this pointer's value produces
    undefined behavior.

    > pathname = argv[1];
    > fdo1 = open("C:/cygwin/home/Jeannie/workspace/hw2/ip.packets.2.txt",
    > O_RDWR);
    > t = now();
    > bytesr = read(fdo1, bufread, 2);


    Even without knowing what the 'read' function is supposed to do, I can
    tell you that passing the uninitialized pointer value 'bufread' to a
    function is undefined behavior all by itself. Most likely, 'read' is
    trying to store data into the memory pointed to by 'bufread', but
    'bufread' does not point to any valid memory.

    You probably need to change the definition of 'bufread' to something
    like:

    unsigned char bufread [SOME_NUMBER];

    ....where SOME_NUMBER is a value that is large enough to hold the
    maximum amount of data that will be stored there.

    > t = now() - t;
    > printf("time %.3f\n", t);
    > exit(0);
    > }


    With almost no exceptions, standard and even non-standard functions in
    C that take a pointer variable require that the pointer actually
    points to valid existing memory. This is almost certainly the case
    with your 'read' function.

    If you have more questions about the extensions like 'read', 'open',
    and 'gettimeofday', which are not standard C, the best group to ask
    would be news:comp.unix.programmer.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Sep 24, 2005
    #2
    1. Advertising

  3. ferbar

    Skarmander Guest

    ferbar wrote:
    > Hi all,
    >
    > I'm trying to read from the txt file 'ip.packets.2.txt' using the read
    > function. It seems everything ok, but I get a -1 when executing
    >
    >
    >>>bytesr = read(fdo1, bufread, 2);

    >
    >
    > The 'open' function returns the file dsc 3. So this seems ok..
    >
    > Any idea what might be wrong?
    >

    <snip>
    open() and read() are Unix functions, they're not standard C. Any reason
    you can't use fopen() and fread()? Especially since (judging from the
    pathname) you're running on Windows anyway. You wouldn't need Cygwin if
    you used the standard I/O functions.

    Check the value of errno to find out what went wrong. For example:

    #include <string.h>
    #include <errno.h>

    ....

    bytesr = read(fdo1, bufread, 2);
    if (bytesr < 0) {
    printf("Can't read from file: %s", strerror(errno));
    }

    Note that "bufread" must point to initialized memory. You can't just
    pass in a void*. You probably meant to declare a buffer like

    unsigned char bufread[BUFSIZE];

    S.
     
    Skarmander, Sep 24, 2005
    #3
  4. ferbar wrote on 24/09/05 :
    > I'm trying to read from the txt file 'ip.packets.2.txt' using the read
    > function. It seems everything ok, but I get a -1 when executing
    >
    >>> bytesr = read(fdo1, bufread, 2);


    Not standard C.

    Please use standard C (fopen(), fread() etc.) on c.l.c, or go to a unix
    group.

    --
    Emmanuel
    The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
    The C-library: http://www.dinkumware.com/refxc.html

    "C is a sharp tool"
     
    Emmanuel Delahaye, Sep 24, 2005
    #4
  5. "ferbar" <> writes:
    > I'm trying to read from the txt file 'ip.packets.2.txt' using the read
    > function. It seems everything ok, but I get a -1 when executing
    >
    >>>bytesr = read(fdo1, bufread, 2);

    >
    > The 'open' function returns the file dsc 3. So this seems ok..
    >
    > Any idea what might be wrong?


    The open() and read() functions are not defined in standard C. The
    standard C equivalents are fopen() and fread(). There are valid
    reasons for using the non-portable versions (in non-portable code),
    but this isn't the place to ask about them.

    If you want to try using fopen() and fread(), this is the place to
    ask; for open() and read(), try comp.unix.programmer. (It looks like
    you're using Cygwin, but I don't think you're doing anything
    Cygwin-specific.)

    Having said that, I have a couple of comments.

    > #define BUFSIZE 1024
    >
    > #include <fcntl.h>
    > #include <sys/time.h>
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <unistd.h>
    >
    > double now() {
    > struct timeval t;
    > gettimeofday(&t,NULL);
    > return ((double)t.tv_sec + (double)t.tv_usec/1000000.0);
    > }
    >
    > int main(int argc, char** argv) {
    > int fdo1;
    > double t;
    > char * pathname;
    > ssize_t bytesr;
    > void * bufread;
    >
    > pathname = argv[1];
    > fdo1 = open("C:/cygwin/home/Jeannie/workspace/hw2/ip.packets.2.txt",
    > O_RDWR);
    > t = now();
    > bytesr = read(fdo1, bufread, 2);
    > t = now() - t;
    > printf("time %.3f\n", t);
    > exit(0);
    > }


    You say that the open() function returns 3, and read() returns -1, but
    there's no indication in your code that you actually checked the
    values. Apparently what you posted isn't the actual code you're
    talking about.

    For fopen(), you *always* need to check whether the file was opened
    successfully; the same applies to open(). And the code you posted
    assigns the result of read() to bytesr, but doesn't use it; presumably
    there's something useful you could do with that result.

    You set pathname to argv[1] (without checking whether there actually
    is an argv[1]) -- but then you don't use it.

    Finally (and I think this is your real problem), the variable bufread
    is never initialized before being passed to read(). I'm not going to
    comment here on what read() does with its second argument; it's
    sufficient to say that any reference to an uninitialized variable
    invokes undefined behavior. The name "bufread", and the fact that
    it's of type void*, tend to imply that it should be a pointer to a
    buffer. You need to make it point to a buffer that's large enough for
    whatever you're going to use it for.

    That's about all I can say without going beyond standard C.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Sep 24, 2005
    #5
  6. Jack Klein <> writes:
    [...]
    > With almost no exceptions, standard and even non-standard functions in
    > C that take a pointer variable require that the pointer actually
    > points to valid existing memory. This is almost certainly the case
    > with your 'read' function.


    With no exceptions at all, any function that takes a pointer argument
    requires that the pointer either points to valid existing memory, or
    has the value NULL. Even if the function itself allowed an
    uninitialized value (e.g., if another argument tells the function to
    ignore the value), evaluating the uninitialized variable would invoke
    undefined behavior before the function is called.

    (When I say "no exceptions at all", I'm ignoring non-portable hacks
    like using (void*)-1 as a special value. Even if you assume that's
    valid, an uninitialized value is not.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Sep 24, 2005
    #6
  7. ferbar

    ferbar Guest

    Yes, I have to use non-standard. You are right, this is not the forum.
    I posted in comp.unix.programmer too.

    But thanks all for being kind enough to respond anyways... About the
    pointer, true. No way it could work with uniniatialized pointers.

    Thanks!

    FBM
     
    ferbar, Sep 24, 2005
    #7
  8. "ferbar" <> writes:
    > Yes, I have to use non-standard. You are right, this is not the forum.
    > I posted in comp.unix.programmer too.
    >
    > But thanks all for being kind enough to respond anyways... About the
    > pointer, true. No way it could work with uniniatialized pointers.


    Once again:

    If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Sep 24, 2005
    #8
  9. ferbar

    Jack Klein Guest

    On Sat, 24 Sep 2005 21:24:52 GMT, Keith Thompson <> wrote
    in comp.lang.c:

    > Jack Klein <> writes:
    > [...]
    > > With almost no exceptions, standard and even non-standard functions in
    > > C that take a pointer variable require that the pointer actually
    > > points to valid existing memory. This is almost certainly the case
    > > with your 'read' function.

    >
    > With no exceptions at all, any function that takes a pointer argument
    > requires that the pointer either points to valid existing memory, or
    > has the value NULL. Even if the function itself allowed an
    > uninitialized value (e.g., if another argument tells the function to
    > ignore the value), evaluating the uninitialized variable would invoke
    > undefined behavior before the function is called.
    >
    > (When I say "no exceptions at all", I'm ignoring non-portable hacks
    > like using (void*)-1 as a special value. Even if you assume that's
    > valid, an uninitialized value is not.)


    This time I think you misinterpreted me.

    The wording "With almost no exceptions, standard and even non-standard
    functions in C that take a pointer variable require that the pointer
    actually points to valid existing memory" is worded the way it is
    because some functions, such as free() and strtol(), are defined to
    accept null pointer arguments, which most certainly do not point "to
    valid existing memory."

    So my wording as written is correct, and at the time it seemed
    unimportant to distinguish between null and uninitialized pointers. It
    seems perhaps a little less unimportant now.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Sep 25, 2005
    #9
  10. Jack Klein <> writes:
    > On Sat, 24 Sep 2005 21:24:52 GMT, Keith Thompson <> wrote
    > in comp.lang.c:
    >
    >> Jack Klein <> writes:
    >> [...]
    >> > With almost no exceptions, standard and even non-standard functions in
    >> > C that take a pointer variable require that the pointer actually
    >> > points to valid existing memory. This is almost certainly the case
    >> > with your 'read' function.

    >>
    >> With no exceptions at all, any function that takes a pointer argument
    >> requires that the pointer either points to valid existing memory, or
    >> has the value NULL. Even if the function itself allowed an
    >> uninitialized value (e.g., if another argument tells the function to
    >> ignore the value), evaluating the uninitialized variable would invoke
    >> undefined behavior before the function is called.
    >>
    >> (When I say "no exceptions at all", I'm ignoring non-portable hacks
    >> like using (void*)-1 as a special value. Even if you assume that's
    >> valid, an uninitialized value is not.)

    >
    > This time I think you misinterpreted me.
    >
    > The wording "With almost no exceptions, standard and even non-standard
    > functions in C that take a pointer variable require that the pointer
    > actually points to valid existing memory" is worded the way it is
    > because some functions, such as free() and strtol(), are defined to
    > accept null pointer arguments, which most certainly do not point "to
    > valid existing memory."
    >
    > So my wording as written is correct, and at the time it seemed
    > unimportant to distinguish between null and uninitialized pointers. It
    > seems perhaps a little less unimportant now.


    Sure. I was expanding on what you wrote, not disagreeing.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Sep 25, 2005
    #10
    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. Doug
    Replies:
    3
    Views:
    4,390
    Bruce Barker
    Nov 4, 2005
  2. Xiangliang Meng
    Replies:
    1
    Views:
    1,629
    Victor Bazarov
    Jun 21, 2004
  3. Kaush
    Replies:
    5
    Views:
    393
  4. Xeno Campanoli
    Replies:
    1
    Views:
    352
    James Britt
    Jul 1, 2005
  5. Paul
    Replies:
    2
    Views:
    154
Loading...

Share This Page