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

 

[Bartc]

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.

 

[Harald van Dijk]

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]

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.

 

[Harald van Dijk]

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]

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

....

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]

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

...

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.