On Tuesday, July 29, 2003, at 12:48 PM, Guy Harris wrote:
Some comments:
Some more comments:
1) "long" should not be used in data structures that correspond to data
from a file, as "long" is 32 bits on some platforms supported by
Ethereal and 64 bits on others. I changed the record data structures
in 5views.c to use "guint32" for 32-bit quantities and "guint16 for
16-bit quantities - those are also discussed in the "Portability"
section of "doc/README.developer".
2) It was unable to read your sample file on my machine:
[gharris:cmd/ethereal/wiretap] gharris% uname -p
powerpc
PowerPC processors *can* run in little-endian mode, but this one
doesn't run in that mode:
[gharris:cmd/ethereal/wiretap] gharris% uname -s
Darwin
You can't assume that numerical data items in a file are in the same
byte order as the processor on which you're reading the file - you have
to convert from the byte order in the file (little-endian, in your
case) to the host byte order, using the "phto..." and "pleto..."
macros.
Similarly, you have to convert *from* the host byte order *to* the
appropriate byte order when *writing* a file.
3) "wtap_dump_close()" will free any opaque pointer you put into a
"wtap_dumper" structure - you don't need to free it yourself in your
close routine and, if you do, the item pointed to by that pointer will
be freed twice.
I've checked in fixes for those problems.
