Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2023 14:00:29 -0700
From: enh <>
To: Paul Eggert <>
Cc:, Time zone mailing list <>
Subject: Re: thread-safe localtime() for an arbitrary timezone

On Mon, Jun 19, 2023 at 11:08 PM Paul Eggert <> wrote:

> On 2023-06-15 10:03, enh wrote:
> > any thoughts on either renaming `struct state` (i went with `struct
> > __timezone_t` to match the typedef to timezone_t for the pointer) or
> having
> > a knob for that (i added a `#define state __timezone_t` in the `#if
> > NETBSD_INSPIRED` in private.h)? why do i care? because tzcode pulls in
> the
> > system <time.h>, which is actually fine for the tzcode code, but breaks
> the
> > OpenBSD wcsftime().
> We could rename 'struct state', but I'm a bit lost as to what the
> problem is, as I don't see mention of 'state' or 'timezone_t' in
> openbsd/lib/libc/time/wcsftime.c. Although there is a 'struct state' in
> openbsd/lib/libc/time/localtime.c I assume you're replacing that with
> tzcode's localtime.c somehow.

it's actually the openbsd strptime.c that's unhappy:
In file included from bionic/libc/tzcode/strptime.c:40:
bionic/libc/tzcode/private.h:790:23: error: typedef redefinition with
different types ('struct state *' vs 'struct __timezone_t *')
typedef struct state *timezone_t;
bionic/libc/include/time.h:46:30: note: previous definition is here
typedef struct __timezone_t* timezone_t;
1 error generated.
the trick in private.h assumes that it's #included _before_ <time.h>, but
that's not true in that file.

(since we already have local changes in that file for gnu extensions that
openbsd wasn't interested in, i've just reordered the #includes.)

User apps (which tzcode is, by default) shouldn't define symbols like
> __timezone_t because these symbols are reserved to the system. We could
> easily rename 'struct state' to 'struct timezone_struct' so that you
> could compile with -Dtimezone_struct=__timezone_t, though I'm still
> curious about why 'struct state' causes problems.

true; since tzcode _is_ the implementation for 3.5+ billion devices, i
forget that others might not consider it "the implementation" :-)

> I'll cc this to the tz mailing list to see whether other people there
> have insight into this issue. For those new to the discussion, the
> original thread is archived here:

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.