ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] OS X and Win32 buildbots unhappy with mpeg.c

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 21 Aug 2007 20:01:07 -0700
I've checked in a change that should fix this.

A couple of rules for developers:

1) If you're doing 64-bit arithmetic, and assigning the result to a 32-bit quantity:

1) make sure that either the result will always fit in 32 bits, you check for results that don't fit and handle that case with the appropriate error handling, or you're willing to live with a bogus result if it doesn't fit;

2) once you've done any checking for results that don't fit, if you're doing any, explicitly cast the result to the type of the item to which you're assigning it, so that the compiler knows you're aware of the issue and have done what you consider appropriate, and won't warn you about it.

2) Do NOT create 64-bit integral constants by sticking "LL" at the end of the constant; MSVC++ 6.0, for example, doesn't recognize that. Instead, wrap the constant in G_GINT64_CONSTANT(), e.g. don't do "0x123456789abcLL", do "G_GINT64_CONSTANT(0x123456789abc)".

The latter of those is covered in the "Portability" section of doc/ README.developer; that section lists a number of rules for portability, many of which are there because of code submitted to Ethereal/Wireshark that, for example, "worked in GCC" but failed in other compilers.

The former of those arguably should be covered in doc/README.developer as well.