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.