[tz] Invalid tm handling in %s pattern in strftime

enh enh at google.com
Mon Jun 6 22:56:16 UTC 2022

On Mon, Jun 6, 2022 at 2:41 PM Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 6/6/22 13:25, enh wrote:
> > int saved_errno = errno;
> > errno = 0;
> > if (mktime() == -1 && errno != 0) {
> That isn't portable, because mktime can set errno and then successfully
> return -1, which means the caller can't rely on errno to decide whether
> mktime succeeded. I'm pretty sure this sort of behavior can happen on
> popular platforms.

we certainly try to avoid that mistake on Android, but, yeah, i've
definitely seen bugs like that.

> This sort of thing isn't a problem with syscalls like 'open', where the
> caller can portably distinguish success from failure by testing whether
> the return value is negative. Unfortunately, it is a problem with
> 'mktime', where the caller cannot portably distinguish success from
> failure. Even main-branch TZDB strftime isn't 100% reliable here on all
> platforms; it's merely more reliable than inspecting errno would be.
> > (the specific issue on 32-bit Android [where time_t is 32-bit] is that
> this
> > ends up using mktime64() which takes a *const* struct tm for historical
> > reasons.
> Does Android mktime64() reliably leave errno alone when it succeeds? If
> so, perhaps we could add a compile-time macro like
> "MKTIME_SETS_ERRNO_ONLY_ON_FAILURE" that would let strftime use code
> like what's quoted above.

it's your mktime(), so you tell me :-) but if you meant "does the extra
cruft that _isn't_ tzcode mktime() touch errno?", no, it doesn't touch
errno directly, nor does it call anything other than mktime() that might
set errno. (or if you actually meant "look how hard it is to prove such
things", yeah :-( in bionic we use RAII to make functions "errno clean" all
the time to avoid this kind of problem because it's too hard to reason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20220606/bc98051a/attachment.htm>

More information about the tz mailing list