Wireshark-dev: Re: [Wireshark-dev] [Patch] pragma warning
From: Guy Harris <[email protected]>
Date: Mon, 2 Apr 2007 16:40:05 -0700
On Apr 2, 2007, at 4:13 PM, Stephen Fisher wrote:

We're still compiling epan/dissectors with a ton of warnings from
auto-generated dissectors on Unix.
How many of them are coming from asn2wrs-generated dissectors?

asn2wrs is, for some reason, generating a lot of dissect_ functions that aren't being called.
I think it might also be generating some hf_ values that aren't being  
used, although I might be thinking of some other set of generated  
dissectors with that problem.
There is only one warning left from the regular dissectors and I'm not
quite sure how to fix it properly:

packet-diameter.c: In function `dissect_avps':
packet-diameter.c:2057: warning: comparison between signed and unsigned
The relevant code is:

       if ( data.secs >= NTP_TIME_DIFF){

Where data is a nstime_t (and secs is a time_t).  NTP_TIME_DIFF is
defined as 2208988800UL since it's too large to be a signed int/long.
We don't support platforms on which "int" is shorter than 32 bits, so  
2208988800U *should* suffice, unless there's something I'm missing.

time_t is typically a signed value, but isn't guaranteed to be from what
I've read.
According to RFC 2030 (which defines the NTP time stamp format also  
used in Diameter), the NTP time stamp is unsigned.  Therefore, the  
seconds field of an NTP time stamp should be fetched into a guint32_t  
Then, the relevant code would be

	if (ntp_timestamp_secs >= NTP_TIME_DIFF) {

which is comparing two unsigned values.

Inside that branch of the if, I'd do

		data.secs = ntp_timestamp_secs - NTP_TIME_DIFF;

with "data" being the nstime_t.

Making the value LL (long long) is only officially supported
in c99, not the c90 that we code to. Any ideas on how to fix this in a
portable fashion?
64-bit integer support isn't needed for this, but as a general FYI on  
64-bit integer support in Wireshark, gint64_t or guint64_t are  
supported on all the platforms we support (we no longer support  
platforms where the compiler and formatted-output routines don't  
support 64-bit integral data types).