On 10/29/25 06:06, Pádraig Brady wrote:
Note the following does show one unconditional use of the fprintftime
return in tar:
https://codesearch.debian.net/search?q=%3D+*fprintftime+*%5C%28&literal=0
So it might be plausible to change that and also change fprintftime()
to return -1 on error (like fprintf).
Last December, as part of some integer-overflow fixes in GNU Tar, I
changed it to assume that fprintftime returns a negative value on error.
The above-cited code now looks like this:
len = add_printf (len,
(tm ? fprintftime (fp, fmt, tm, 0, ts.tv_nsec)
: fprintf (fp, "????""-??""-?? ??:??:??")));
where add_printf takes intmax_t arguments, checks for intmax_t overflow
when adding, and assumes a negative count means an error occurred. I
made the GNU Tar change assuming that fprintftime acts like printf with
respect to integer overflow errors.
If we changed fprintftime to return intmax_t, with -1 meaning there was
an error (possibly intmax_t overflow) and errno being set, this would
fix the bug in the above GNU Tar code. This change could be combined
with Collin's proposed patch, and the combination would be better than
Bruno's (a), (b), and (c) alternatives because the result of fprintftime
would be well-documented and reliable. (The rushdb example Bruno gave
will still compile, and will still misbehave in very-unlikely
circumstances, but that's on rushdb not us.)
