>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.