On 1/3/07, Guy Harris <[EMAIL PROTECTED]> wrote:
Martin Mathieson wrote:> For the more general problem, I see 2 possible solutions: > (1) have both signed and values in the union, and use the appropriate > signed or unsigned parts of the union in the comparison functions > (2) leave the union as it is with unsigned members, cast values in all > the signed versions instead of the unsigned versions I vote for solution 1 (and have everything that adds a signed value to the protocol tree set the signed value in the union).
The attached patch tries to implement (1), and seems to work (in the limited testing I've done). However, it ended up touching more files than I expected (a couple of dissectors even!). There are still 2 or 3 places where signed and unsigned FT types are still handled together by treating the value as guint32, thus potentially losing -ve values of FT_INT32 fields, I've preserved the existing behaviour for now. I would appreciate if someone could review this patch. It does correct a real problem, although I expect signed 32 bit fields with negative values are pretty rare in most protocols (I'd guess they're more likely to appear as generated fields). I suppose 64-bit numerical fields theoretically have the same problem, but is presumably even less likely to cause real problems...? Best regards, Martin
signedfields.diff.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
