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

On 2022-03-21 10:07, jdoubleu wrote:
> Hi,
> 
> On 2/25/2022 5:39 PM, Brian Inglis wrote:
>>
>> define POSIX specified minimum TZ abbr size 3 TZNAME_MIN
>> use limits.h TZNAME_MAX, _POSIX_TZNAME_MAX, unistd.h 
>> sysconf(_SC_TZNAME_MAX)
>> issue error if no symbols defined (document fallback value in case 
>> required)
>> allow POSIX angle bracket < > quoted signed alphanumeric tz abbr e.g. 
>> <MESZ+0330>
>> allow POSIX unquoted alphabetic tz abbr e.g. MESZ
>> apply same changes for DST tz abbr
>> ---
>>   newlib/libc/time/tzset_r.c | 74 ++++++++++++++++++++++++++++++++------
>>   1 file changed, 64 insertions(+), 10 deletions(-)
>>
> 
>> +      /* quit if no items, too few or too many chars, or no close 
>> quote '>' */
>> +      if (sscanf (tzenv, "%10[-+0-9A-Za-z]%n", __tzname_std, &n) <= 0
>> +        || n < TZNAME_MIN || TZNAME_MAX < n || '>' != tzenv[n])
>> +        return;
> 
> Is it safe to use the minus (-) as first char in the sscanf format set: 
> "%10[-+0-9A-Za-z]%n"?

The first and last positions are the only generally safe places to 
specify the hyphen/minus as part of the set and not part of a range.

> Newlib's sscanf docs states 
> (https://sourceware.org/newlib/libc.html#sscanf):
>> There is also a range facility which you can use as a shortcut. %[0-9] 
>> matches all decimal digits. The hyphen must not be the first or last 
>> character in the set.

I read that as saying that the first or last character within the 
brackets can not be the hyphen a la [--@] or [!--], as it then stands 
alone, and is not treated as part of a range, allowing the hyphen/minus 
to be one of the characters matched, as is also the case when the first 
and last characters are not lexically ordered e.g. [z-a] == z|-|a.
I presume this is a lexer limitation to allow safe and efficient range 
and set scanning.

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