On 10/15/21 3:03 PM, Alejandro Colomar (man-pages) wrote:
Actually, since timegm(3) is implemented in terms of mktime(3), as far as I could read from glibc code, the problem will be the same, I think.
No, because another thread could setenv ("TZ", ...) between the time
that you call mktime and the time you look at the 'timezone' variable.
So even though mktime itself is thread-safe, the expression 'mktime(tm)
- timezone' is not.
But timegm(3) shouldn't need to depend on environment variables.
It does depend, if leap seconds are involved.
and the subtraction might overflow.
Yup, casting to int64_t needed.
That would help, but it still wouldn't suffice. It'd mishandle -1
returns, for example. Plus, we're better of not putting today's hardware
assumptions into code (suppose int is 64 bits in future machines?).
BTW, I had a look at mktime source
code, and it uses long, which might be 32 bits, and then there's a lot
of checking for overflow.
mktime uses long_int, which is not necessarily 'long'. And no matter
what type you pick, it could overflow on some platform, even if it's an
only-hypothetical platform now.
