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. > > _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
