Hi list,
Why not?
Two reasons really,
First, creating a new type which has no accessors would be easier,
especially since I dont know how much about
how tvbuff works. Also, I made the assumption that the accessors, which I
assume only are called from dissectors
would not really be that important to use when the data has "holes".
(if it has holes, there is no point in dissectong it)
I wanted to avoid changing all the existing accessors because I am lazy.
Second, by requiring that all applications first must extract a normal
COMPOSITE from it before any data can be accessed,
I would automatically get the start of data to be at offset 0. Also I was
not sure if any existing dissectors might be very "upset" if suddenly
there were "holes" in the data for the packet. I understand now that this is
a moot point since no existing dissector is aware of
this concept and no existing dissector could be affected.
I think that changing the existing type COMPOSITE to allow insertion of
REAL/SUBSETs at arbitrary point in the 4Gb buffer space
would be a much better solution.
I dont know yet how this would affect the tvb_lengthXXX functions. What is
the remaining length if there are holes? To the end of the last populated
fragment? To the end of the current fragment? etc?
Would something break?
I will think this over...
----- Original Message -----
From: "Guy Harris" <guy@xxxxxxxxxx>
To: "Ronnie Sahlberg" <rsahlber@xxxxxxxxxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Sent: Wednesday, May 23, 2001 7:34 AM
Subject: Re: [Ethereal-dev] RFC: new TVBUFF type
> > This type of TVBUFF can be created and destroyed as any other TVBUFF,
though
> > none of the accessorts or any
> > other functions in tvbuff.c can operate on this TVBUFF.
>
> Why not?
>
> Why not simply change composite tvbuffs so you can add stuff in
> arbitrary places and have holes?
>
> Attempts to fetch data from holes would throw a new exception type.
> (Note that a "hole" due to, for example, a tvbuff having a length
> shorter than its reported length would cause a BoundsError exception to
> be thrown, not a new type of exception.)
