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

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.

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.

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:

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.