[LCP]sockets problem

[Mike & Penny Novack]

 > Although unlikely, it's possible that len will have a negative
> value after the read(), so it should not be used as an array
> index without checking.  The snippet in question should be more
> like this:
>
>     if ((len = read(sockno, buffer, 34)) < 0)
>         scream_and_die();
>     buffer[len] = 0;  /* make sure the string is null terminated! */
>
> I didn't really check the whole thing, because it was a pretty
> good discussion of the issues -- but this one jumped out at me.
>
> Greg

To make Greg's comment clearer, ALWAYS CHECK FUNCTION CALLS (ie: for the
"error" return as well as valid value). In this case, read ()returns the
number of characters read IF it worked or -1 if it failed. This is an
example of combining error indication along with return values by
selecting an impossible value as the "error code". In other cases, you
may need to check some global indicator. BTW, this particular mistake
used to nail programmers where I used to work all the time (ie:
confusion between nothing returned meaning "no data found to be
retrieved" and the error indicator meaning "operation FAILED" ----- not
finding requested data in a database is not normally an error).

Let me add something liable to get me flamed. I am not a big fan of
treating things like "buffer overflow" as things to be dealt with
automatically by a "better" language (eg: automatic runtime subscript
bound checking, etc.). Here's the problem. Essentially you end up
thinking you don't ALWAYS need to be asking "what are the range of valid
values" (how do I process those) and "what are ALL the possible invalid
values" (AND what action must the program take in each situation). See,
the program dependent upon "automatic" prevention has NO specified
"action". OK, you think of "program hangs but nothing damaged" as
acceptable, but hung program means some standby programmers gets called
in the middle of the night (or perhaps just a few dozen to a few hundred
"users" sitting at terminals which won't respond).

As a designer/coder I have to ask, if somebody coding isn't even aware
of the OBVIOUS possibility of data entered not being the right type or
size (and hasn't made any provisions to "field" this error) then what
more subtle bugs are possibly also being ignored.? The automatic
"safety" doesn't really save time coding because the correct version
STILL needs explicit code to "field" the error (provide a meaningful
error message, take necessary actions to clear the offending transaction
or whatever so the application can proceed, or maybe close down
gracefully, etc.). I look at the read() situation somewhat differently,
not that "error" is unlikely but rather that there are THREE possible
outcomes of the operation; it might have failed with an error (deal with
that), it might have worked but returned nothing (deal with that), or it
returned data (process that). It's not unusual in a properly designed
program that 50% of the lines deal with conditions that will probably
never occur, another 30% for handling rare situations and boundary
conditions, and only 20% actually "getting the work done".

Mike