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

[enh]

On Wed, Jun 21, 2023 at 12:54 AM Guy Harris <gharris at sonic.net> wrote:

> From an earlier message of yours:
>
>         https://www.openwall.com/lists/libc-coord/2023/06/15/2
>
> sent only to libc-coord:
>
> > writing some basic unit tests for these functions went fine, though it
> was
> > sad that i couldn't use `std::unique_ptr<timezone_t, decltype(&tzfree)>
> > seoul{tzalloc("Asia/Seoul"), tzfree}` because the size of timezone_t
> isn't
> > known. i'd be tempted to further mangle this so i have a public struct
> > containing a large-enough char[], but i worry about just how large to
> make
> > it to be safe from future tzcode changes. (and on the other hand, do i
> > think that tzalloc() is going to be used frequently enough to warrant the
> > effect? probably not?)
>
> Is there some particular reason to make timezone_t an API/ABI structure,
> rather than a pointer to an opaque structure?
>

no, my preference would be for timezone_t to be more like DIR...

typedef struct DIR DIR;

means you need to write the * in signatures, but that std::unique_ptr-style
safe usage "just works" without having to talk about the underlying struct
or use std::remove_pointer.


> Presumably if it's a structure, "tzalloc()" really means "given a tzid,
> fill in a structure as appropriate for that tzid, and return that
> structure", not "allocate a structure, fill it in as appropriate for the
> tzid, and return a pointer to that structure", and "tzfree()" means "free
> up anything pointed to by the structure whose value was passed to it"
> rather than "free everything pointed to by the structure pointed to by the
> argument and then free the structure".  If you want to do that, perhaps
> names that don't imply that they allocate and free a timezone_t should be
> chosen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20230621/d13cd34b/attachment.htm>