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
value.
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).
