[tz] [libc-coord] thread-safe localtime() for an arbitrary timezone

[enh]

On Mon, Jun 19, 2023 at 11:08 PM Paul Eggert <eggert at cs.ucla.edu> 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:
>
> https://www.openwall.com/lists/libc-coord/2023/06/14/1
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20230620/772ea294/attachment.htm>