[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2D1CCCE8-0F37-48B7-8820-4D3DA76342A1@sonic.net>
Date: Wed, 21 Jun 2023 00:54:37 -0700
From: Guy Harris <gharris@...ic.net>
To: enh <enh@...gle.com>
Cc: Paul Eggert <eggert@...ucla.edu>, Time zone mailing list <tz@...a.org>,
libc-coord@...ts.openwall.com
Subject: Re: [tz] thread-safe localtime() for an arbitrary
timezone
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?
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.
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.
