[PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs
Wed Feb 16 19:18:31 GMT 2022
On 2022-02-16 01:55, Corinna Vinschen wrote:
> On Feb 15 22:38, Brian Inglis wrote:
>> 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
>>> 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:
>> and the value used should be that configured:
>> 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
>> 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!
> I'd replace 6 with #error
That's probably for the best - I'll look at adding that to a v2 patch
set including doc update.
What is required to remake newlib libc info and man pages?
Do I need to specify a special target or maintainer mode?
Updated tzset.def libc.info are not showing up in my build or install
dirs! I am sure I had all the tools and this used to work reliably.
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.]
More information about the Newlib