Re: [PATCH 2/2] tzset_r.c(_tzset_unlocked_r): POSIX angle bracket <> support

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2022-04-07 03:56, jdoubleu wrote:
>> +#include <limits.h>    /* {,_POSIX_}TZNAME_MAX */
>> ... > +#define TZNAME_MIN    3    /* POSIX min TZ abbr size local def */
>> +#define TZNAME_MAX    10    /* POSIX max TZ abbr size local def */
> 
> The comment suggests, that `TZNAME_MAX` is coming from `limits.h`, isn't 
> it?

 From previous comments, we are no longer using those predefined values, 
just those used locally in the code, and the minimum from the POSIX spec.

> Everything else looks good to me.
> Unfortunately, I wasn't able to test these changes, yet. I cannot easily 
> build newlib for my project. However, I've prepared some tests vectors 
> (see 
> https://github.com/jdoubleu/newlib-posix-tzset-tests/blob/main/timezones.h), 
> which I plan to integrate with the newlib testsuite.

Feel free to look at tzset_t.log attached to my ...testing post:

	tzset/_r POSIX tz abbr angle bracket <> support testing
	https://sourceware.org/pipermail/newlib/2022/019529.html

and add the 103 unique TZ=... values used there, extracted from the end 
of the latest tzdb tzdata /usr/share/zoneinfo/ files, as they include 
actual exceptional times and offsets to achieve the required transitions 
and challenge implementation parsers and calculations.
See the tzcode/tzdata project zic(8)/zdump(8)/tzfile(5) implementation 
limits for how wide those limits need to extend.

> 🙎🏻‍♂️ jdoubleu
> On 4/5/2022 6:03 AM, Brian Inglis wrote:
>>
>> local defines for POSIX minimum TZ abbr size 3 TZNAME_MIN and
>> maximum TZ abbr size supported 10 TZNAME_MAX
>> allow POSIX angle bracket < > quoted signed alphanumeric tz abbr e.g. 
>> <MESZ+0330>
>> allow POSIX unquoted alphabetic tz abbr e.g. MESZ
>> allow same suuport for DST tz abbr
>> ---
>>   newlib/libc/time/tzset_r.c | 67 +++++++++++++++++++++++++++++++-------
>>   1 file changed, 55 insertions(+), 12 deletions(-)

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