read(2) problem on p9p?

read(2) problem on p9p?

[EBo]

This might be a stupid question, but I have a regression test that is
returning an unintuitive result from a read(2).  The relevant part of the
regression test follows:

    char *tst_str = "this is a test... this is only a test.";

    ret = fprint(dtf, tst_str);
    test(strlen(tst_str)==ret,2,
     "write  %s to variable\n",tst_str);

    // zero out so I know I have clean data
    memset(buf,0,sizeof buf);

    // FIXME: read returns 0, but reads the buff as
    //   expected.  The docs, read(2), sais that a return of
    //   0 suggests eof, but suggests that read should
    //   otherwise return the number of bytes read.
    ret = read(dtf, buf, 1024);
    test(strlen(tst_str)==ret,4, "read back from var\n");
    close(dtf);

    test(!strcmp(tst_str,buf)==ret,4, "check value\n");

Basically the above writes a string to a file reads it back and checks the
value.  All that works except for the value returned by read.  The docs
state that read should return the number of bytes read, and a 0 implies
eof.  I the above case I asked it to read a huge block which read all the
data in the file correctly, but also read to the end of file.  Shouldn't
read return nbytes (strlen(tst_str) in this case), and return 0 if I try to
read past EOF again?  If this is not the plan9 way, how do I check for how
many bytes was read in?

Just to be clear, the last test succeeded -- I read in the entire string
back in and succeeded.

  EBo --

Re: [9fans] read(2) problem on p9p?

[erik quanstrom]

>     test(!strcmp(tst_str,buf)==ret,4, "check value\n");

you haven't explanined what the arguments to test do, but
you appear to be mixing strcmp idioms.  i think you wish either

	test(strcmp(test_str, buf) == 0, 4, "check value\n");

or
	test(!strcmp(test_str, buf), 4, "check value\n");

- erik

Re: [9fans] read(2) problem on p9p?

[EBo]

> you haven't explanined what the arguments to test do, but
> you appear to be mixing strcmp idioms.  i think you wish either
>
> 	test(strcmp(test_str, buf) == 0, 4, "check value\n");
>
> or
> 	test(!strcmp(test_str, buf), 4, "check value\n");

Right. Sorry...  The declaration for test is:

  void test(int bool, int space, ...);

where bool is the test case to prepend a pass/fail message in front of the
used defined message printed by vfprint.  Space is a pretty printing addon
that prints n spaces before the print message -- it makes it easier to
read.

The test you pointed out was a bad test.  Thanks for catching that!

The real problem was the test before it:

    ret = read(dtf, buf, strlen buf);
    test(strlen(tst_str)==ret,4, "read back from var\n");

Read actually correctly reads the file correctly (which the next test
verifies), but since I asked it to read 1K bytes when the message length is
only 39, read returns 0 instead of 39 and sets the file's offset to the end
of file as I would have expected.

I also should add if I did not before, this is on plan9port.


  EBo --

Re: [9fans] read(2) problem on p9p?

[Skip Tavakkolian]

i'm wondering if it has to do with writing/reading the same file (dtf)
without readjusting the offset (i.e.  does pread behave differently)?

also about this:

	test(!strcmp(tst_str,buf)==ret,4, "check value\n");

do you mean to say

	test(strncmp(tst_str,buf,ret) != 0, 4, "check value\n");


> This might be a stupid question, but I have a regression test that is
> returning an unintuitive result from a read(2).  The relevant part of the
> regression test follows:
>
>     char *tst_str = "this is a test... this is only a test.";
>
>     ret = fprint(dtf, tst_str);
>     test(strlen(tst_str)==ret,2,
>      "write  %s to variable\n",tst_str);
>
>     // zero out so I know I have clean data
>     memset(buf,0,sizeof buf);
>
>     // FIXME: read returns 0, but reads the buff as
>     //   expected.  The docs, read(2), sais that a return of
>     //   0 suggests eof, but suggests that read should
>     //   otherwise return the number of bytes read.
>     ret = read(dtf, buf, 1024);
>     test(strlen(tst_str)==ret,4, "read back from var\n");
>     close(dtf);
>
>     test(!strcmp(tst_str,buf)==ret,4, "check value\n");
>
> Basically the above writes a string to a file reads it back and checks the
> value.  All that works except for the value returned by read.  The docs
> state that read should return the number of bytes read, and a 0 implies
> eof.  I the above case I asked it to read a huge block which read all the
> data in the file correctly, but also read to the end of file.  Shouldn't
> read return nbytes (strlen(tst_str) in this case), and return 0 if I try to
> read past EOF again?  If this is not the plan9 way, how do I check for how
> many bytes was read in?
>
> Just to be clear, the last test succeeded -- I read in the entire string
> back in and succeeded.
>
>   EBo --

Re: [9fans] read(2) problem on p9p?

[Russ Cox]

it would help if you posted a complete program.

Re: [9fans] read(2) problem on p9p?

[EBo]

> i'm wondering if it has to do with writing/reading the same file (dtf)
> without readjusting the offset (i.e.  does pread behave differently)?
>
> also about this:
>
> 	test(!strcmp(tst_str,buf)==ret,4, "check value\n");
>
> do you mean to say
>
> 	test(strncmp(tst_str,buf,ret) != 0, 4, "check value\n");

Turned out to be a read hearing.  The real problem is that I corrupted the
file name and the size got set to 4.  Now I have two more test case to add
;-)

Both pread and seek/read combo's work as expected

Sorry for the bother.


  EBo --

Re: [9fans] read(2) problem on p9p?

[EBo]

> it would help if you posted a complete program.

I will make a point of doing so in the future, but...  This is part of an
automated regression test suite and is separate from the server.  Sending
you the complete system would at this point require sending the entire
source-base to compile and test.

That is why I posted a code snippet instead of sending the whole code base
-- which I thought a bit excessive at this point.

  EBo --

Re: [9fans] read(2) problem on p9p?

[Russ Cox]

>> it would help if you posted a complete program.
>
> I will make a point of doing so in the future, but...  This is part of an
> automated regression test suite and is separate from the server.  Sending
> you the complete system would at this point require sending the entire
> source-base to compile and test.
>
> That is why I posted a code snippet instead of sending the whole code base
> -- which I thought a bit excessive at this point.

No, you shouldn't send the whole code base.
You should take the time to cut the program down to
a short demonstration of the problem before posting to
the list.  9 times out of 10 you find, as was the case
here, that the problem is not where you thought it was,
and you avoid the list post entirely, saving the time of
the many readers and your time too, since you get the
answer faster.

Russ

Re: [9fans] read(2) problem on p9p?

[erik quanstrom]

> Turned out to be a read hearing.

ha!  :-)

- erik

Re: [9fans] read(2) problem on p9p?

[EBo]

> No, you shouldn't send the whole code base.
> You should take the time to cut the program down to
> a short demonstration of the problem before posting to
> the list.  9 times out of 10 you find, as was the case
> here, that the problem is not where you thought it was,
> and you avoid the list post entirely, saving the time of
> the many readers and your time too, since you get the
> answer faster.

I agree, but to get that specific test to work (writing to a file that is
synthetically generated my the system) requires running against the server
I'm working on, which in turn requires almost all the code I have to date
(minus the other regression tests).  I know that this is WAY to much to
send the list without a very good reason.  All I was asking is that if
there was something obvious wrong.  In most cases I do take the time to
trim it down to a standalone case (like I did with dirreadall failing when
run on in-memory trees).

The problem turned out to be that I wrote "add tst_var type int" to ctl --
which creates an int variable (which is 4 bytes).  All of my later tests
assumed I was working with strings.  So, a seek or pread fixed the obvious
problem, but the underlying one length was due to it was doing exactly what
I asked it to ;-)  So, this discussion pointed the way to two other bugs.

  EBo --