On May 1, 2011, at 6:06 AM, Martin Kaiser wrote:
> I'm working on messages that contain a UTC time info. To display this in
> the protocol tree as FT_ABSOLUTE_TIME, I should store the time info in
> an nstime_t variable. The output then looks like
>
> Aug 18, 2010 10:32:11.000000000
>
> as nstime_t has nanosecond precision. Is there any chance to limit this
> to seconds only (that's all my protocol uses)?
Currently, no.
We would need to either:
1) add to nstime_t an indication of the precision of the time value (and decide what happens if you add or subtract two time values of different precision - does the result have the precision of the higher-precision operand?)
or
2) add a precision indication to the definition of FT_{ABSOLUTE,RELATIVE}_TIME fields, to indicate how they should be displayed.
> 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....)
For a more realistic example, it would work for a 32-bit time-in-seconds-since-the-Epoch value, too.
You still have to set nsecs to 0, of course.
> What about the other direction
>
> col_append_sep_fstr(pinfo->cinfo, COL_INFO, NULL,
> "time info is %d seconds", (int)my_time.secs);
>
> Is it ok to do this in wireshark
No, because time_t can be larger than an int.
> or is there a more portable way?
col_append_sep_fstr(pinfo->cinfo, COL_INFO, NULL,
"time info is %ld seconds", (long)my_time.secs);
would probably work better.
