Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > open and read functions (can't make 'read' work..)

Reply
Thread Tools

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

 
 
ferbar
Guest
Posts: n/a
 
      09-24-2005
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);
}

 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      09-24-2005
On 24 Sep 2005 12:59:19 -0700, "ferbar" <(E-Mail Removed)> 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/~a...FAQ-acllc.html
 
Reply With Quote
 
 
 
 
Skarmander
Guest
Posts: n/a
 
      09-24-2005
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.
 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      09-24-2005
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"


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-24-2005
"ferbar" <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-24-2005
Jack Klein <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
ferbar
Guest
Posts: n/a
 
      09-24-2005
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

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-24-2005
"ferbar" <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      09-25-2005
On Sat, 24 Sep 2005 21:24:52 GMT, Keith Thompson <(E-Mail Removed)> wrote
in comp.lang.c:

> Jack Klein <(E-Mail Removed)> 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/~a...FAQ-acllc.html
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-25-2005
Jack Klein <(E-Mail Removed)> writes:
> On Sat, 24 Sep 2005 21:24:52 GMT, Keith Thompson <(E-Mail Removed)> wrote
> in comp.lang.c:
>
>> Jack Klein <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Static functions and C++ member functions mafiQ C++ 0 04-22-2009 08:33 PM
Re: how to open a file in some application using Tkinter i am usingTKINTER to create GUI application i want to know how to open a worddocument in open office or any other applicatio Fredrik Lundh Python 1 01-09-2008 10:40 AM
Does ruby have a similar functions to the Python dir and help functions? py Ruby 5 03-24-2007 08:54 AM
private virtual functions and pure virtual functions with bodies John Goche C++ 10 12-08-2006 04:00 PM
please help me in distinguish redefining functions, overloading functions and overriding functions. Xiangliang Meng C++ 1 06-21-2004 03:11 AM



Advertisments