From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) by sourceware.org (Postfix) with ESMTPS id B2855386103B for ; Tue, 17 Nov 2020 04:59:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B2855386103B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id et5VkaTpftdldet5WkkFDs; Mon, 16 Nov 2020 21:59:30 -0700 X-Authority-Analysis: v=2.4 cv=INe8tijG c=1 sm=1 tr=0 ts=5fb358b2 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=ZqF515WzAAAA:20 a=uZvujYp8AAAA:8 a=xXsHP_Tb37vO6jCbm18A:9 a=QEXdDO2ut3YA:10 a=tyy7ts44EHAA:10 a=aAUpaOR82PcA:10 a=AomDDAB-fV4A:10 a=tFKFYrkxXOwA:10 a=8xPuELMIaLgA:10 a=SLzB8X_8jTLwj6mN0q5r:22 Reply-To: newlib@sourceware.org To: newlib@sourceware.org References: <080401d6bada$6c52f060$44f8d120$.ref@yahoo.com> <080401d6bada$6c52f060$44f8d120$@yahoo.com> <20201116151359.GD41926@calimero.vinschen.de> <3a5f706a-f1c0-595f-ff96-e674cb72e233@SystematicSw.ab.ca> From: Brian Inglis Organization: Systematic Software Subject: Re: [PATCH] Add support for TZ names with <> in tzset Message-ID: <76c91228-465f-1c99-9a8e-6269063b04bd@SystematicSw.ab.ca> Date: Mon, 16 Nov 2020 21:59:29 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfL8P/B+Swfk2FTc9bbhCsN/0X8ikiAIwYYUOkzn5D0Td8+nI1XbBU6MhCVu7HayxJ2BOADKNImLxQaMAi0bRsMKwHN85hzSypI9m/Dd82ilOKYCUB0fP Gm6sleDsOjLw3X/xwHCdhT7Dd9VlJxfaigp38L8bBaDZo4xyxogWfX6bpiRvC27uee96x2xODp7kgQHju9NK6HEhYngHbMHOZB0= X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 04:59:33 -0000 On 2020-11-16 18:43, C Howland via Newlib wrote: > On Monday, November 16, 2020 5:30 PM, Brian Inglis wrote: >> On 2020-11-16 08:13, Corinna Vinschen via Newlib wrote: >>> On Nov 14 15:03, Earle F. Philhower, III via Newlib wrote: >>>> 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. >>>> >>> 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. > The proposal is missing the documentation update (in tzset.c) for the new > feature. (This of course is needed regardless of the eventual method by > which it is achieved.) > Also, one question: since at present the TZ string is matching POSIX (at > least, it is according to the documentation--I did not check the present > source code against the statement), shouldn't there be a gate to control > whether the extension is included or not? (In my tzset(3) man page in RHEL7, > GLIBC does not mention this particular extension, so I don't know what gate > they might use.) Strictly there should be; the question is how strict we > want to be. The <> quoted format has been a POSIX standard since Issue 6 IEEE Std 1003.1, 2004; see under Base Definitions, 8.3 Other Environment Variables, bottom of web page, under TZ: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.htmltag_08_03 also Rationale, A.8.3 Other Environment Variables, bottom of web page, under TZ: https://pubs.opengroup.org/onlinepubs/009695399/xrat/xbd_chap08.html#tag_01_08_03_05 and not an extension, intended to allow specification of signed alpha/numeric character time zone designations, not just the original alphabetic character designations, with at least 3 not more than TZNAME_MAX (minimum _POSIX_TZNAME_MAX == 6) characters. The POSIX TZ env var current spec is essentially unchanged under Base Definitions, 8.3 Other Environment Variables, bottom of web page, under TZ: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03 also Rationale, A.8.3 Other Environment Variables, bottom of web page, under TZ: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap08.html#tag_21_08_03_05 where the leading : for implementation defined zones is treated as optional by implementations supporting zoneinfo TZif files, and better implementations will handle relative paths specially (normally prefix with TZDIR, or at least start by trying that location, then try alternatives), and allow and handle absolute paths in the obvious way. Perhaps Eric Blake if available could shed more light as a POSIX contributor. -- 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.]