I was testing the buffer size of system call, read(), and found a
strange error on Ubuntu 7.10 server. The code is attached.

If the BUFFSIZE is set to from 128 to 255, the code will produce an error as

read error: Success

If the if statement (and the perror) is removed, the error disappears.

I have tried the same program on Sun Solaris 5.10 and got the same results.

The program read from the standard input and write to standard output.
Use any large file as the input redirected to standard input and dump
the output to null.

How to test:

../a.out < AnySufficientLargeFile >/dev/null

----------------------------------------

#include <stdio.h>
#include <unistd.h>

#define BUFFSIZE 128

int main(void)
{
char n;
char buf[BUFFSIZE];

while ((n = read(STDIN_FILENO, buf, BUFFSIZE)) > 0)
if (write(STDOUT_FILENO, buf, n) != n)
perror("write error");

if (n < 0)
perror("read error");
return 0;
}
-----------------------------------------

Larry said:

> I was testing the buffer size of system call, read(), and found a
> strange error on Ubuntu 7.10 server. The code is attached.

Check the return type of read() - I think you'll find that it's not char,
and that fixing it to be the right type will fix your problem.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

"Larry" <larry_web@hotmail.com> wrote in message
news:ftrt67$u65$1@aioe.org...
>I was testing the buffer size of system call, read(), and found a strange
>error on Ubuntu 7.10 server. The code is attached.
>
> If the BUFFSIZE is set to from 128 to 255, the code will produce an error
> as
>
> read error: Success
>
> If the if statement (and the perror) is removed, the error disappears.

Naturally..


> char n;
....
> if (n < 0)
> perror("read error");
> return 0;
> }

As RH has said, the char n is the problem.

But for this code, n needs to be unsigned, in which case the 'if (n<0)'
should be a compilation error. And if n is signed, it's maximum range seems
to be 127.

--
Bart

On Sun, 13 Apr 2008 10:21:48 +0000, Bartc wrote:
> But for this code, n needs to be unsigned, in which case the 'if (n<0)'
> should be a compilation error.

Huh? If n is unsigned, it will never be less than zero, but why would
checking that anyway result is a compilation error? What if you're
dealing with a typedef that may be signed or unsigned, depending on the
system, and you want to check that a value is in the range of [0 .. 10]?
It shouldn't be and isn't an error to check
if (n < 0 || n > 10) /* handle error */

(This thread was posted to comp.os.linux, but according to my ISP, it
doesn't exist. Newsgroups set to comp.lang.c only.)

"Harald van D?k" <truedfx@gmail.com> wrote in message
news:38090$4801e839$541dfcd3$3400@cache4.tilbu1.nb .home.nl...
> On Sun, 13 Apr 2008 10:21:48 +0000, Bartc wrote:
>> But for this code, n needs to be unsigned, in which case the 'if (n<0)'
>> should be a compilation error.
>
> Huh? If n is unsigned, it will never be less than zero, but why would
> checking that anyway result is a compilation error?

gcc produces this message:

c:\c>gcc c.c
c.c: In function `main':
c.c:8: warning: comparison is always false due to limited range of data type

Well, OK, it's a warning not an error.

--
Bart

Harald van D?k wrote:
>
.... snip ...
>
> (This thread was posted to comp.os.linux, but according to my ISP,
> it doesn't exist. Newsgroups set to comp.lang.c only.)

Your ISP is wrong. It probably simply means it doesn't subscribe
to that newsgroup, which is ridiculous, since c.o.l is a principal
group.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

On Sun, 13 Apr 2008 11:26:26 -0400, CBFalconer wrote:
> Harald van D?k wrote:
>>
> ... snip ...
>>
>> (This thread was posted to comp.os.linux, but according to my ISP, it
>> doesn't exist. Newsgroups set to comp.lang.c only.)
>
> Your ISP is wrong. It probably simply means it doesn't subscribe to
> that newsgroup, which is ridiculous, since c.o.l is a principal group.

Are you sure about that? I can access c.o.l.* without problems, but
that's not what this thread was posted to. According to the archives on
Google Groups, there hasn't been any message to c.o.l itself since 2005
either.

Newsgroups reset again, since I can't post otherwise.

Bartc wrote:

> "Larry" <larry_web@hotmail.com> wrote in message
> news:ftrt67$u65$1@aioe.org...
>
>>I was testing the buffer size of system call, read(), and found a strange
>>error on Ubuntu 7.10 server. The code is attached.
>>
>>If the BUFFSIZE is set to from 128 to 255, the code will produce an error
>>as
>>
>>read error: Success
>>
>>If the if statement (and the perror) is removed, the error disappears.

Which error? The [apparently] erroneous statement printed, or the error in
your code. Without the 'if()' statment, your code error is still there
(just not so obvious, but could bite you later and you'd be pulling your
hair out trying to track it down - follow RH's advice).

....
>>char n;
>>
> ...
>
>>if (n < 0)
>>perror("read error");
>>return 0;
>>}
>>
>
> As RH has said, the char n is the problem.

Not in the if() statement per se (that would depend upon the compiler - see
below).

> But for this code, n needs to be unsigned,

Really? My impression is that for that code it /needs/ to be signed.

> in which case the 'if (n<0)'
> should be a compilation error. And if n is signed, it's maximum range seems
> to be 127.

Possibly, depending upon compile options; most compilers I've used will
usually attempt some auto-cast, guessing what the programmer intended.

And then again, the error may, or may not, appear depending upon what the
compiler defines for a 'char'.