[Martin Kaiser <lists@xxxxxxxxx>]

Hello Guy, all,

thanks for your feedback.

Thus wrote Guy Harris (guy@xxxxxxxxxxxx):

> > In order to populate the nstime_t, I set the seconds directly, e.g.

> > nstime_t my_time;
> > my_time.secs = tvb_get_guint8(tvb, offset);

> > Is this portable enough with the implicit cast between guint8 and
> > time_t?

> That would be an issue only if there were a system where time_t is a
> signed 8-bit value, and, since such a system would have a problem at
> 12:02:07 UTC, January 1, 1970, you're unlikely to ever see such a
> system.

> (Of course, a protocol with an unsigned
> absolute-time-in-seconds-since-the-Epoch field would have a problem at
> 12:04:15 UTC, January 1, 1970, so, in practice, you're not going to
> see a protocol with a field that's an FT_ABSOLUTE_TIME where you set
> the secs field directly to an 8-bit value.  FT_RELATIVE_TIME, perhaps,
> as long as intervals less than 256 seconds....)

the code snippet above is actually for a relative time (uint8 interval).
I convert this and get it to be displayed cleanly using
rel_time_to_str(). But is it the recommended way to use FT_RELATIVE_TIME
rather than FT_UINT8 for such a time interval?

There's a second relative time in the protocol: an int16 offset that is
encoded as a 2's complement of 2 bytes.


static inline gint16 two_comp_to_int16(guint16 x)
{
   return (x&0x8000) ? -~(x-1) : x;
}


[...]

   nstime_set_zero(&local_offset);
   local_offset.secs = 60 *
      (time_t)two_comp_to_int16(tvb_get_ntohs(tvb, offset));

   proto_tree_add_time_format(...
      rel_time_to_str(&local_offset));


This works fine as long as time_t is a signed type. Can I safely assume
that this is true on all platforms wireshark runs on or should I avoid
FT_RELATIVE_TIME here and use FT_INT16?

Thanks,

   Martin