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 < AnySufficientLa rgeFile >/dev/null

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

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

#define BUFFSIZE 128

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

while ((n = read(STDIN_FILE NO, buf, BUFFSIZE)) 0)
if (write(STDOUT_F ILENO, buf, n) != n)
perror("write error");

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

[Richard Heathfield]

Re: Strange I/O error

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]

Re: Strange I/O error


"Larry" <larry_web@hotm ail.comwrote 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

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

Re: Strange I/O error

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]

Re: Strange I/O error


"Harald van D?k" <truedfx@gmail. comwrote in message
news:38090$4801 e839$541dfcd3$3 400@cache4.tilb u1.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]

Re: Strange I/O error

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==?=]

[OT] Re: Strange I/O error

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]

Re: Strange I/O error

Bartc wrote:

"Larry" <larry_web@hotm ail.comwrote 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("rea d 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]

Re: Strange I/O error


"Robert Newson" <ReapNewsB@bull et3.fsnet.oc.ku wrote in message
news:480265FC.3 010105@bullet3. fsnet.oc.ku...

Bartc wrote:
>

>"Larry" <larry_web@hotm ail.comwrote in message
>news:ftrt67$u6 5$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("re ad 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]

Re: [OT] Re: Strange I/O error

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