https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16519

Guy Harris <ghar...@sonic.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |IN_PROGRESS
     Ever confirmed|0                           |1

--- Comment #4 from Guy Harris <ghar...@sonic.net> ---
(In reply to Chuck Craft from comment #3)
>     if (cap_duration) /* XXX - shorten to hh:mm:ss */
>         printf("Capture duration:    %s\n",
> relative_time_string(&cf_info->duration, cf_info->duration_tsprec, cf_info,
> TRUE));
> 
> is calling:
> 
> relative_time_string(nstime_t *timer, int tsprecision, capture_info
> *cf_info, gboolean want_seconds)
> {
>   const gchar  *second = want_seconds ? " second" : "";
>   const gchar  *plural = want_seconds ? "s" : "";
>   static gchar  time_string_buf[4+1+2+1+2+1+2+1+2+1+2+1+1];
> 
> Which has a buffer length of 21: 4+1+2+1+2+1+2+1+2+1+2+1+1 and truncates the
> output string:
> 
>    g_snprintf(time_string_buf, sizeof time_string_buf,

         111111111122
123456789012345678901
171658.044391 second

That fits *exactly* in 21 bytes, so, yes, the "s" overflows the buffer.

The longest possible duration, with a 64-bit unsigned time_t and nanosecond
time resolution, is 18446744073709551615.999999999 seconds; that's 39
characters, including the trailing '\0'.

> absolute_time_string(nstime_t *timer, int tsprecision, capture_info *cf_info)
> {
>   static gchar  time_string_buf[4+1+2+1+2+1+2+1+2+1+2+1+9+1+1];
> 
> Has a longer buffer length of 31: 4+1+2+1+2+1+2+1+2+1+2+1+9+1+1

I'll check that one to see if *it* handles the maximum, too.

That length value looks as if it's constructed assuming the form YYYY-MM-DD
HH:MM:SS.SSSSSSSSS, although it's 1 byte longer than necessary for that.

I'm not sure *where* the length value came from for the relative times, given
that they aren't displayed as YYYY-MM-DD etc.

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to