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] nstime_t, time_t, typecasts

From: Marc Petit-Huguenin <marc@xxxxxxxxxxxxxxxxxx>
Date: Sat, 28 May 2011 19:25:46 -0000

Martin Kaiser <lists@xxxxxxxxx> wrote:

>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
>___________________________________________________________________________
>Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>Archives:    http://www.wireshark.org/lists/wireshark-dev
>Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe