[PATCH v2 2/2] timegm.3: Remove recommendation against use of timegm()
Alejandro Colomar (man-pages)
alx.manpages@gmail.com
Fri Nov 5 00:47:50 GMT 2021
Hi Paul,
On 10/18/21 00:00, Paul Eggert wrote:
> On 10/17/21 11:02, Alejandro Colomar (man-pages) wrote:
>
>> timegm(3) is the only non-error-prone solution in glibc for using UTC
>> times, so it should not be marked as "avoid using".
>
> timegm is not portable, so it's reasonable for the documentation to warn
> against its use. Perhaps the warning could be made clearer.
Well, there's no portable alternative, as we discussed, so if a program
needs to do what timegm(3) does (handle UTC dates), it needs to call it.
The only portable alternatives are using other libraries such as boost
(C++). I prefer porting timegm(3) to those platforms instead. Since
C2X will add timegm(3), it's good news.
>
>
>> - int is unlikely to be >32 bits.
>
> There are a few platforms where int is >32 bits (these are typically
> ILP64).
Interesting; I didn't know that. What a weird thing.
> Although glibc doesn't currently support them, let's not place
> unnecessary obstacles in the way.
>
>
>> - Even if int ever happened to be 64 bit, this problem would still be
>> something very theoretical
>
> The behavior of the 'zdump' command would change. I imagine it'd affect
> other commands as well. Admittedly most people wouldn't notice.
>
>
>> if (tm->tm_year > SOME_ARBITRARY_HUGE_VALUE
>
> Let's not impose arbitrary limits.
Since glibc doesn't support 64-bit 'int' yet, the following restriction
could be added without altering the behavior of any existing program:
[
If any of the fields of 'struct tm' would overflow 'int32_t', the
behavior of timegm(3) is undefined.
]
It is arbitrary, yes, but in reality, the code would handle correctly
more than INT32_MAX; it would only cause overflow for values close to
INT64_MAX.
Moreover, it would only affect those weird platforms.
And in those cases:
- If the date is something sane, UB will never be triggered.
- If the date can be compromised (e.g., user input), the only thing that
the programmer needs to do to avoid UB, is to store the temporary values
in int32_t variables before storing them in the struct tm. That will
handle any overflow by truncating it (if the programmer wants to do
something else, that's fine, but it's the minimum to avoid UB). Not
much of a problem.
It would simplify very much glibc code, by imposing small restrictions
to the user.
Don't you think?
Thanks,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
More information about the Libc-alpha
mailing list