Strange I/O error

Discussion in 'C Programming' started by Larry, Apr 13, 2008.

  1. Larry

    Larry Guest

    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, Apr 13, 2008
    #1
    1. Advertising

  2. Larry

    Bartc Guest

    "Larry" <> wrote in message
    news:ftrt67$u65$...
    >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
    Bartc, Apr 13, 2008
    #2
    1. Advertising

  3. 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 Dijk, Apr 13, 2008
    #3
  4. Larry

    Bartc Guest

    "Harald van D?k" <> wrote in message
    news:38090$4801e839$541dfcd3$1.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
    Bartc, Apr 13, 2008
    #4
  5. [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.
    Harald van Dijk, Apr 13, 2008
    #5
  6. Bartc wrote:

    > "Larry" <> wrote in message
    > news:ftrt67$u65$...
    >
    >>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'.
    Robert Newson, Apr 13, 2008
    #6
  7. Larry

    Bartc Guest

    "Robert Newson" <> wrote in message
    news:...
    > Bartc wrote:
    >
    >> "Larry" <> wrote in message
    >> news:ftrt67$u65$...
    >>
    >>>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
    Bartc, Apr 13, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Panic
    Replies:
    2
    Views:
    5,209
    Marc Guardiani
    Oct 24, 2003
  2. kwaj
    Replies:
    1
    Views:
    423
    Egbert Molenkamp
    Mar 7, 2004
  3. Jan
    Replies:
    2
    Views:
    1,426
    Mike Treseler
    Dec 16, 2004
  4. Harvey Twyman
    Replies:
    8
    Views:
    560
    August Derleth
    Oct 25, 2003
  5. Sam
    Replies:
    2
    Views:
    145
    Bob Barrows [MVP]
    Nov 16, 2007
Loading...

Share This Page