[LCP]sockets problem

[Paul Gearon]

On Tue, 29 Jan 2002, Mike & Penny Novack wrote:

> 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

<snip>

I can't agree more.  I actually didn't immediately spot the bug in the
accept() call of Srinath's code.  I tracked it down by checking return
values, and "errno" when appropriate.  It's the only way to write code,
but I left a lot of this out when posting earlier.

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

OK, I don't want to flame, but I will disagree.  :-)  (This is likely to
get ME flamed).

Typically languages like this (I'm thinking of Java here, but I assume
some of the others are similar) don't return values like C does.  In C
your only have a single return machanism (let's forget passing pointers
for a second).  Hence the value returned indicates success/failure, as
well as a relevant value for the success case.

In other languages you have a different return path (exceptions) when an
error occurs.  That means that if you got a value back then it succeeded,
so you don't have to check it.  OTOH you *must* check for these exceptions
in exactly the same way that a C coder must check for invalud return
values.  I've seen Java and C++ coders who don't bother checking for
specific exceptions, and just handle a general exception or pass it on.
This is just as bad as letting a C program segfault.

There are numerous advantages to this (when it's used correctly!), but a
big problem I have with it is efficiency.  eg. Every array index is
implicitly bounds checked, every dereference is implicitly checked for a
null pointer.  C is a LOT better in this regard because a programmer can
know when a check is necessary.

<snip>
> 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".

Exactly, though this is the reason why the code for people "learning" new
stuff will often not check for all the errors.  It's a lot of overhead for
someone who's probably quite happy to live with a segfault while they
learn to get it right.

The reason I like Stevens' book so much is exactly because he not only
checks return values ALL the time, he does it in such a way that it
doesn't break the flow of the code and makes it easy to follow.  That way
it doesn't look like 80% of the code does nothing but handle things that
shouldn't happen.


Regards,
Paul Gearon

Software Engineer                Telephone:   +61 7 3876 2188
Plugged In Software              Fax:         +61 7 3876 4899
http://www.PIsoftware.com        PGP Key available via finger

Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum
immane mittam.
(Translation from latin: "I have a catapult. Give me all the money,
or I will fling an enormous rock at your head.")