public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
To: newlib@sourceware.org
Subject: Re: [PATCH] Add support for TZ names with <> in tzset
Date: Mon, 16 Nov 2020 15:30:56 -0700	[thread overview]
Message-ID: <3a5f706a-f1c0-595f-ff96-e674cb72e233@SystematicSw.ab.ca> (raw)
In-Reply-To: <20201116151359.GD41926@calimero.vinschen.de>

On 2020-11-16 08:13, Corinna Vinschen via Newlib wrote:
> Hi Earle,
> 
> On Nov 14 15:03, Earle F. Philhower, III via Newlib wrote:
>> Howdy all,
>>
>> Attached is a patch which extends the tzset() function to support a format
>> for "unnamed" TZ environment timezones which use "<+/-nn>" as the timezone
>> name instead of an alphabetic name.  These are supported in glibc and are
>> present in several major TZ databases that we use on the ESP8266 Arduino
>> core.  For example,
>>
>>> #define TZ_Africa_Casablanca	  "<+01>-1"
>>
>> The existing tzset sscanf format string breaks at the first "+", assuming
>> it's the
>> beginning of the offset.  This patch special-cases names beginning with "<"
>> to
>> circumvent the issue.
>>
>> Signed-off-by: Earle F. Philhower, III   <earlephilhower@yahoo.com>
> 
> Basically this looks ok.  I have two nits, though.
> 
> - Now that the scanning got more complicated than a single sscanf call,
>    this crys out for a helper function doing the actual scanning for
>    both, std and dst strings.  This could be an inline function which is
>    only inlined
>    #if !defined(PREFER_SIZE_OVER_SPEED) && !defined(__OPTIMIZE_SIZE__)
> 
> - The strcat call seems a bit heavy.  What about sth like this instead:
> 
>      __tzname_ptr[n - 1] = '>';
>      __tzname_ptr[n] = '\0';

Should consider modifying the PD TZ project tzcode reference src localtime.c 
tzparse()

	https://github.com/eggert/tz/blob/master/localtime.c#L1069

(contributed to the public domain by Guy Harris): handles all the POSIX rules 
string edge cases to Paul Eggert's satisfaction, and gets patched if any 
upstream org (every distro) or vendor (all OSes) reports a problem.

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

  reply	other threads:[~2020-11-16 22:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <080401d6bada$6c52f060$44f8d120$.ref@yahoo.com>
2020-11-14 23:03 ` earlephilhower
2020-11-16 15:13   ` Corinna Vinschen
2020-11-16 22:30     ` Brian Inglis [this message]
     [not found]       ` <DM2P110MB01699F833CC488133A5AE9E99AE20@DM2P110MB0169.NAMP110.PROD.OUTLOOK.COM>
2020-11-17  1:43         ` Fw: " C Howland
2020-11-17  4:59           ` Brian Inglis
2020-12-12 17:56             ` Earle F. Philhower, III
2020-12-12 18:59               ` Brian Inglis
2020-12-14  9:30               ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a5f706a-f1c0-595f-ff96-e674cb72e233@SystematicSw.ab.ca \
    --to=brian.inglis@systematicsw.ab.ca \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).