Re: record size and wild cards, was change of version string

Andrew Newton writes:
> On Aug 11, 2004, at 12:19 AM, David Blacka wrote:
>
> > I am still trying to imagine *how* this bug could have been written, 
> > but I suppose that is really just a lack of imagination on my part.
> Me too, as in I'm trying to imagine which API they used and why?
The berkeley APIs permit this bug easily. This is very off-charter, but 
if the chair asks I suppose it's okay ;)
Suppose you're reading a packet-based format. Usually the packets are 
something like (type, length, content). (DNS Is slightly different, but 
that doesn't matter right now.)
The protocol parser is supposed to first read the type and length, and 
then 'length' bytes of content.
With the berkeley API, that involves two read() calls. Or maybe just 
one, if you optimize a little. So, first you call select() or poll() to 
be told about the arrival of the data, then read() twice to read them.
If the read() that reads the content returns a short read (that is, the 
program asks for 'length' bytes, the OS returns something less, such as 
1500), then the program _should_ not parse yet, but instead call 
select()/poll() and read() again.
The bug happens when the developers never see a short read and forget to 
handle that case. Short reads don't happen very often often on the 
100Mbps LANs used by most developers.
(I've seen this bug in three products in the past ten years.)

Arnt