Hi Stig, Based on comments from Guy Harris and Bill Meier, I have attached a patch to make the netscaler wiretap code independent of the host system endian-ness. I have taken care of (1) reading and writing nstrace files (netscaler.c) and (2) reading in dissector code (packet-nstrace.c) also.
Please review for commit. thanks, Ravi. On Wed, Nov 18, 2009 at 1:55 PM, <[email protected]> wrote: > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3540 > > > > > > --- Comment #25 from Guy Harris <[email protected]> 2009-11-18 13:55:38 > PDT --- > > I dont see any definitions for letoh[sl]. However there are pletoh[sl] > (epan\pInt.h) macros. > > Those macros are also in <wiretap/wtap-int.h>; you should use those, not > the > ones in <epan/pint.h>, in Wiretap modules such as netscaler.c > > > These definitions are not ifdef-ed in __ppc__ like how GUINT_TO_BE > (Glibconfig.h) macros are done. > > Ifdeffing with __ppc__ is neither necessary nor sufficient. pletoh[sl] > extract > the bytes, one at a time, and assemble them into a 16-bit or 32-bit > quantity; > that is a byte-order-independent operation, so no ifdeffing is necessary. > This > also means that they work regardless of whether the quantity being fetched > is > aligned on the appropriate boundary or not. > > (Ifdeffing with __ppc__ is not sufficient because PowerPC and other flavors > of > the Power Architecture are not the only big-endian architectures in > existence. > The only reason they're ifdeffed in GLib is that GLib has optimized > versions of > PowerPC.) > > > There are lots of users of these macros. Are they susceptible to the same > issue? > > No, they are not. Those macros do the right thing on both little-endian > and > big-endian machines. > > Note also that when *writing* a Netscaler dump, you must convert > host-byte-order values *to* little-endian. See the htole[ls] macros in > wtap-int.h. > > > -- > Configure bugmail: > https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
