Hi,
You're getting the host format and transport format mixed up. The host
format is based on the architecture for the platfom the code runs on. The
transport format is defined by the protocol used to communicate. Between
the two there is to be a translation layer, like the infamous
netinet/in.h macro's ntohs, ntohl, etc. If you want to transport
structured data, you'll have to define your translation layer for that as
well. Depening on eg. Basic Encoding Rules for your transport format, you
most likely can get libraries to do that for you.
Now, if you look at wireshark, it reads directly from the wire, so always
transport format. That is defined by protocol, not host format. If you
want to do more fancy stuff you have to use tvb_get_ntohs() and friends to
make this translation for you.
Thanx,
Jaap
On Sat, 28 Oct 2006, prashanth joshi wrote:
> Hi,
> Suppose the tvb contains a structure and we are supposed to add the structure elements one by one in to the display tree.
> Suppose the structure has the following elements:
> char
> int
> char
> int.
> Now my thinking is ,
> We can not add directly the first item ie char item in to the display tree(using the proto_tree_add_item specifying offset and the length to be added as 1) and then again we can not add directly the second item ie int in to the display tree ( this time offset + 1 and then the length to be added as 4 ) and so on.......
> The reason for my thinking is:
> The structures are padded. So the tvb may actually be containing
> char 4 bytes
> int 4 bytes
> char 4 bytes
> int 4 bytes
> And then I feel structue padding is platform dependent.
> Hence I feel it should be correct first to memcpy the contents using tvb_memcpy from the tvb to a dynamically allocated object. Because i feel the tvb_memcpy takes care of the platform independece issues. And then i feel we can add the structure elements one by one using the proto_tree_add_item(offset , length to be added as 1 )
> and then using, proto_tree_add_item(offset + 1, length to be added as 4).
> Is my assertion about this structure padding and tvb_memcpy correct?
> That is when ever we get a structure in tvb we should not directly add its elements directly to the display tree but we should first memcpy the contents of the tvb using tvb_memcpy, to an alllocated structure object and then we should add the elements one by one in to the display tree?
> Or is this just an imagination of mine.........?
> And one more thing when ever we need to alter the data we need to copy the data in to our memory right? So would it be safer to copy the data from tvb to the local memory ( ie stack memory ) always? I guess ethereal always has a copy of the local memory contents that we add to the display tree. So this avoids the dangling reference issues. So is using the heap memory to copy the contents from the tvb totally discouraged by the ethereal? I've written the code in such a way that i dont need to store the data for later reference. But at some places I've still used
> g_malloc( ) to allocate the memory ( I've an older version of ethereal and it does not support the ep_alloc ( ) ). So now i can just use locally defined arraya to store the tvb data?
> Regards,
> Prashanth.
>
>
