Jan 14 03:05:06 +0100 2003 Andreas Oberritter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as >subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
