Strange I/O error

[Larry]

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

[Richard Heathfield]

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

[Bartc]

"Larry" <la*******@hotmail.comwrote in message
news:ft**********@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

[Harald van =?UTF-8?b?RMSzaw==?=]

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

[Bartc]

"Harald van D?k" <tr*****@gmail.comwrote in message
news:38**************************@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

[CBFalconer]

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

[Harald van =?UTF-8?b?RMSzaw==?=]

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.

[Robert Newson]

Bartc wrote:

"Larry" <la*******@hotmail.comwrote in message
news:ft**********@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'.

[Bartc]

"Robert Newson" <Re*******@bullet3.fsnet.oc.kuwrote in message
news:48**************@bullet3.fsnet.oc.ku...

Bartc wrote:

>"Larry" <la*******@hotmail.comwrote in message
news:ft**********@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.

Well, if the OP had a pressing reason for using a char type for n, then it
needed to be unsigned to accommodate buffer sizes of 128 to 255. In this
case perhaps the erroneous negative values possibly would be eliminated.

But if those read/write functions could return negative statuses, then
you're right, the OP needs to move up to a wider, signed type.

--
Bart

[CBFalconer]

Harald van D?k wrote:

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.

That (no messages) may well be true, since it seems to be an outer
'containment' group, with about 20 subgroups. My ISP doesn't
complain about the cross-post, but may simply delete it. I know
that posting to non-existent groups produces violent annoyance
messages here.

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