[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Jun 2023 23:08:54 -0700
From: Paul Eggert <eggert@...ucla.edu>
To: enh <enh@...gle.com>
Cc: libc-coord@...ts.openwall.com, Time zone mailing list <tz@...a.org>
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:
https://www.openwall.com/lists/libc-coord/2023/06/14/1
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.
