From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7f852ecf5053f87338ba74df57418ed1@9netics.com>
To: 9fans@9fans.net
Date: Fri, 13 Aug 2010 10:51:37 -0700
From: Skip Tavakkolian <9nut@9netics.com>
In-Reply-To: <669f246aba1d324e377a93d730962f41@swcp.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] read(2) problem on p9p?
Topicbox-Message-UUID: 483607fa-ead6-11e9-9d60-3106f5b1d025

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 --