Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!pp!lot!ables From: ables@lot.ACA.MCC.COM (King Ables) Newsgroups: comp.unix.wizards Subject: Re: buffer i/o using read(2) on BSD sockets Message-ID: <689@lot.ACA.MCC.COM> Date: 16 Mar 90 22:21:44 GMT References: Organization: MCC, Austin, TX Lines: 33 From article , by mike@turing.cs.unm.edu (Michael I. Bushnell): > In article <85@cvbnetPrime.COM> aperez@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