Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs
Brian Inglis <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Organization | Systematic Software |
| Message-ID | <[email protected]> |
On 2022-02-15 15:04, Brian Inglis wrote: > Submitted a newlib patch which builds okay, but cannot test, as I don't > have a newlib platform to run on, and Cygwin uses it's own TZ DB code base. > It should accept up to 10 character abbreviations for STD and DST > matching POSIX specs including anything within < > quoted content. > If someone needing this could build, test, and send feedback, I'd > appreciate it. > --- > newlib/libc/time/tzset_r.c | 68 ++++++++++++++++++++++++++++++++------ > 1 file changed, 58 insertions(+), 10 deletions(-) Regarding the 10 character limit above, reviewing the POSIX and tzset.c documentation, the size limit should be TZNAME_MAX, so some changes may need to be made to the values or the code, as _POSIX_TZNAME_MAX is the minimum acceptable value: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html and the value used should be that configured: https://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html also: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap08.html#tag_21_08_03_05 newlib/libc/include/sys/unistd.h:#define _SC_TZNAME_MAX 20 newlib/libc/sys/rtems/include/limits.h:#define _POSIX_TZNAME_MAX 3 newlib/libc/sys/rtems/include/limits.h:#define TZNAME_MAX 3 winsup/cygwin/include/limits.h:#define _POSIX_TZNAME_MAX 6 Discussion of whether and how to define and align TZNAME_MAX values are welcome: Cygwin punts and leaves it undefined, so developers have a choice of using the alternatives unistd.h sysconf(_SC_TZNAME_MAX) or _POSIX_TZNAME_MAX. I am inclined to use if defined in order: * limits.h TZNAME_MAX * unistd.h sysconf(_SC_TZNAME_MAX) if available * limits.h _POSIX_TZNAME_MAX * 6! Quoting and limits were changed in The Open Group Technical Standard Base Specifications, Issue 6, April 2004; IEEE POSIX 1003.1-2004. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]