[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2023 14:00:29 -0700
From: enh <enh@...gle.com>
To: Paul Eggert <eggert@...ucla.edu>
Cc: libc-coord@...ts.openwall.com, Time zone mailing list <tz@...a.org>
Subject: Re: thread-safe localtime() for an arbitrary timezone
On Mon, Jun 19, 2023 at 11:08 PM Paul Eggert <eggert@...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
>
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.
