buffer i/o using read(2) on BSD sockets

[King Ables]

>From article <MIKE.90Mar16113811 at turing.cs.unm.edu>,
  by mike at turing.cs.unm.edu (Michael I. Bushnell):
> In article <85 at cvbnetPrime.COM> aperez at cvbnet.UUCP
> (Arturo Perez x6739) writes:
> 
>>This is one of my pet peeves about BSD sockets.
>
> Nothing new.  The same is true of terminal I/O.  

But we're not talking about terminal i/o.  And anyway, "it's always
been that way" is no justification for the way something works (or
doesn't as the case may be).

> All you need is:
> [some code to take care of knowing how much data you got with
>  the read() so you can keep read()ing until you get it all.]

Sure, it works.  But Arturo's whole point is that you shouldn't
*need* to do that!  Everyone who has ever had this problem has
had to re-invent the same wheel.  Okay, it's not a complicated 
wheel, granted.  And I understand why when terminal i/o gets 
involved and you're trying to write generic code to work on all
kinds of i/o streams that you want to make lowest common denominator
assumptions about capability.  But making everyone in the world write
their own version of read() to act like the real thing for their
sockets isn't the answer, either.

Don Libes' little library of socket i/o calls (that he referenced in
a message here when this thread started) does a nice job of "fixing"
the problem... too bad a few calls like this weren't in some BSD library
in the first place.

-king