Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: EOVERFLOW with section filter



 Jan 14 03:05:06 +0100 2003 Andreas Oberritter <andreas@oberritter.de> wrote:
> On Tue, 2003-01-14 at 01:27, Jeremy Hall wrote:
> > all of the code I've seen reads 3 bytes, determines the length, then reads
> > the correct amount.
> 
> I've definitively seen other code, too. :-)
> 
> What is the benefit of doing two reads instead of one? Being able to
> malloc(section_length + 3) and to copy the first three bytes to the
> section buffer manually? The maximum section size is known to be 4096
> bytes, so having a static buffer should be sufficient for most
> applications.

It depends how the driver delivers data to the read() caller (I don't
know whether kernel intervents this further..). But, at least in theory,
this could happen:

len = read(fd, buf, 4096)

len returns 3072.

The length encoded in buf (in byte offsets 0, 1, 2): 2048.

After 2048 bytes, there is next length encoded in buffer,
(now in byte offsets 2048, 2049, 2050) which could be 
like 4096 (in which 1024 (3072 - 2048) bytes is already read).

Now one does not have space in the buffer for still
unread 3072 (4096 - 1024) (*), and data shift is required...

It is much easier to read first those 3 bytes, and then
length. Otherwise, depending how read() behaves in this
case, some more complex code needs to be developed to
handle data... In worst case scenario, read may return
anything between 1 and full requested amount of data
in each read() call.

Tomi

(*) OK, the length might not include the length info,
but in this example thinking like that serves good...



> 
> Regards,
> Andreas
> 
> 
> 
> -- 
> Info:
> To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index