From: Paul Eggert <eggert@cs.ucla.edu>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
Joe Simmons-Talbott <josimmon@redhat.com>,
libc-alpha@sourceware.org
Subject: Re: [PATCH] time: strftime_l: Use malloc rather than an unbounded alloca.
Date: Tue, 16 May 2023 15:00:59 -0700 [thread overview]
Message-ID: <cd17e5d4-9aba-637e-6a37-ed230a2d3437@cs.ucla.edu> (raw)
In-Reply-To: <cd305746-2662-dca0-f364-80acd3e19dab@linaro.org>
On 5/16/23 12:28, Adhemerval Zanella Netto via Libc-alpha wrote:
> Do we have a practical maximum size for the abbreviate timezone name? The
> internal tz_rule 'name' field is just a pointer, but I think all timezones
> uses a maximum name size.
In current TZDB data the longest abbreviation has four bytes (e.g.,
"AKST", "NZST"). Before TZDB release 2016g (2016-09-13) the longest was
48 bytes, for the Factory zone's "Local time zone must be set--see zic
manual page" abbreviation.
Although the TZif file format's limit is 2**32 - 1 bytes, the 'zic'
command won't process TZif files with abbreviations longer than about
2000 bytes, due to its internal input line buffer.
There is a limit even if you use long strings in TZ environment
variables, as glibc strftime is buggy when a buffer contains more than
INT_MAX bytes (it uses 'int' to store byte counts). This means you can't
effectively use a time zone abbreviation longer than about 2**31 - 1
bytes with glibc, even on 64-bit platforms. For example, a program like
the one shown below won't work with glibc.
For what it's worth, _POSIX_TZNAME_MAX is 6, that is, every POSIX
platform must support at least 6 bytes.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
int
main ()
{
size_t Xs = (1LL << 32) + 1;
char *tzbuf = malloc (sizeof "TZ=" - 1 + Xs + sizeof "0");
if (!tzbuf)
return perror ("malloc tzbuf"), 1;
size_t strftimebufsize = Xs + 2;
char *strftimebuf = malloc (strftimebufsize);
if (!strftimebuf)
return perror ("malloc strftimebuf"), 1;
strcpy (tzbuf, "TZ=");
memset (tzbuf + 3, 'X', Xs);
strcpy (tzbuf + 3 + Xs, "0");
if (putenv (tzbuf))
return perror ("putenv"), 1;
time_t t0 = 0;
struct tm *tm = localtime (&t0);
if (!tm)
return perror ("localtime"), 1;
size_t nbytes = strftime (strftimebuf, strftimebufsize, "%Z", tm);
if (!nbytes)
return perror ("strftime"), 1;
if (puts (strftimebuf) < 0)
return perror ("puts"), 1;
if (fclose (stdout) < 0)
return perror ("fclose"), 1;
return 0;
}
next prev parent reply other threads:[~2023-05-16 22:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 19:59 Joe Simmons-Talbott
2023-05-16 19:28 ` Adhemerval Zanella Netto
2023-05-16 19:53 ` Joe Simmons-Talbott
2023-05-16 22:00 ` Paul Eggert [this message]
2023-05-17 11:04 ` Adhemerval Zanella Netto
2023-05-17 17:40 ` Paul Eggert
2023-05-22 18:35 ` Joe Simmons-Talbott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cd17e5d4-9aba-637e-6a37-ed230a2d3437@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=adhemerval.zanella@linaro.org \
--cc=josimmon@redhat.com \
--cc=libc-alpha@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).