[PATCH] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[PATCH] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Brian Inglis]

[-- Attachment #1: Type: text/plain, Size: 128 bytes --]

---
 newlib/libc/time/tzset_r.c | 68 ++++++++++++++++++++++++++++++++------
 1 file changed, 58 insertions(+), 10 deletions(-)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-newlib-libc-time-tzset_r.c-_tzset_unlocked_r-add-POSIX-quoted-abbrs.patch --]
[-- Type: text/x-patch; name="0001-newlib-libc-time-tzset_r.c-_tzset_unlocked_r-add-POSIX-quoted-abbrs.patch", Size: 2342 bytes --]

diff --git a/newlib/libc/time/tzset_r.c b/newlib/libc/time/tzset_r.c
index 9e0cf834bd6b..5bf463ed3dd7 100644
--- a/newlib/libc/time/tzset_r.c
+++ b/newlib/libc/time/tzset_r.c
@@ -45,8 +45,30 @@ _tzset_unlocked_r (struct _reent *reent_ptr)
   if (*tzenv == ':')
     ++tzenv;  
 
-  if (sscanf (tzenv, "%10[^0-9,+-]%n", __tzname_std, &n) <= 0)
-    return;
+  /* allow POSIX angle bracket < > quoted tz abbr e.g. <+03> */
+  if (*tzenv == '<')
+    {
+      ++tzenv;
+
+      /* scan while dest space left, not EoS, not close quote */
+      for (n = 0;
+	     n < sizeof (__tzname_std) && tzenv[n] && '>' != tzenv[n];
+	       ++n)
+	{
+	  __tzname_std[n] = tzenv[n];
+	}
+
+      /* quit if no chars scanned, not close quote, or too many chars */
+      if (!n || '>' != tzenv[n] || sizeof (__tzname_std) <= n)
+	return;
+
+      __tzname_std[n] = '\0';
+    }
+  else
+    {
+      if (sscanf (tzenv, "%10[^0-9,+-]%n", __tzname_std, &n) <= 0)
+        return;
+    }
  
   tzenv += n;
 
@@ -68,17 +90,43 @@ _tzset_unlocked_r (struct _reent *reent_ptr)
   tz->__tzrule[0].offset = sign * (ss + SECSPERMIN * mm + SECSPERHOUR * hh);
   _tzname[0] = __tzname_std;
   tzenv += n;
-  
-  if (sscanf (tzenv, "%10[^0-9,+-]%n", __tzname_dst, &n) <= 0)
-    { /* No dst */
-      _tzname[1] = _tzname[0];
-      _timezone = tz->__tzrule[0].offset;
-      _daylight = 0;
-      return;
+
+  /* allow POSIX angle bracket < > quoted tz abbr e.g. <+03> */
+  if (*tzenv == '<')
+    {
+      ++tzenv;
+
+      /* scan while dest space left, not EoS, not close quote */
+      for (n = 0;
+	     n < sizeof (__tzname_dst) && tzenv[n] && '>' != tzenv[n];
+	       ++n)
+	{
+	  __tzname_dst[n] = tzenv[n];
+	}
+
+      /* quit if no chars scanned, not close quote, or too many chars */
+      if (!n || '>' != tzenv[n] || sizeof (__tzname_dst) <= n)
+	{ /* No dst */
+	  _tzname[1] = _tzname[0];
+	  _timezone = tz->__tzrule[0].offset;
+	  _daylight = 0;
+	  return;
+	}
+
+	__tzname_dst[n] = '\0';
     }
   else
-    _tzname[1] = __tzname_dst;
+    {
+      if (sscanf (tzenv, "%10[^0-9,+-]%n", __tzname_dst, &n) <= 0)
+	{ /* No dst */
+	  _tzname[1] = _tzname[0];
+	  _timezone = tz->__tzrule[0].offset;
+	  _daylight = 0;
+	  return;
+	}
+    }
 
+  _tzname[1] = __tzname_dst;
   tzenv += n;
 
   /* otherwise we have a dst name, look for the offset */

[PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Brian Inglis]

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 base.
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(-)

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

Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Brian Inglis]

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 base.
> 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:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html

and the value used should be that configured:

https://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html

also:

https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap08.html#tag_21_08_03_05

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

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!

Quoting and limits were changed in The Open Group Technical Standard 
Base Specifications, Issue 6, April 2004; IEEE POSIX 1003.1-2004.

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

Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Corinna Vinschen]

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
> > base.
> > 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:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
> 
> and the value used should be that configured:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html
> 
> also:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap08.html#tag_21_08_03_05
> 
> 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
> _POSIX_TZNAME_MAX.
> 
> 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


Corinna

Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Brian Inglis]

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
>>> base.
>>> 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:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
>>
>> and the value used should be that configured:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/sysconf.html
>>
>> also:
>>
>> https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap08.html#tag_21_08_03_05
>>
>> 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
>> _POSIX_TZNAME_MAX.
>>
>> 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.]

Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Corinna Vinschen]

On Feb 16 12:18, Brian Inglis wrote:
> On 2022-02-16 01:55, Corinna Vinschen wrote:
> > On Feb 15 22:38, Brian Inglis wrote:
> > > 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?

make info / make man?


Corinna

Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Brian Inglis]

On 2022-02-17 05:11, Corinna Vinschen wrote:
> On Feb 16 12:18, Brian Inglis wrote:
>> On 2022-02-16 01:55, Corinna Vinschen wrote:
>>> On Feb 15 22:38, Brian Inglis wrote:
>>>> 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?
> 
> make info / make man?

Thanks for the kick!
I finally found those targets under build64/newlib/Makefile and got 
errors: it looks like python {lxml,ply} need to be manually upgraded to 
python39-{lxml,ply} for these to work!

Both the updated tzset info and man pages now look awful with a 
screenful of run on text!

As far as I can see, I can only use blank lines and angle brackets for 
formatting, so I will add a whole bunch more of those, retry if they 
will now build as part of Cygwin, and see if I can get them to look much 
better.

If anyone has any pointers to the embedded lib doc header semantic 
formatting conventions I would be grateful for those.

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

Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Jon Turney]

On 18/02/2022 03:43, Brian Inglis wrote:
> On 2022-02-17 05:11, Corinna Vinschen wrote:
>> On Feb 16 12:18, Brian Inglis wrote:
>>> On 2022-02-16 01:55, Corinna Vinschen wrote:
>>>> On Feb 15 22:38, Brian Inglis wrote:
>>>>> 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?
>>
>> make info / make man?
> 
> Thanks for the kick!
> I finally found those targets under build64/newlib/Makefile and got 
> errors: it looks like python {lxml,ply} need to be manually upgraded to 
> python39-{lxml,ply} for these to work!
> 
> Both the updated tzset info and man pages now look awful with a 
> screenful of run on text!

That's odd since I would think the viewer should wrap appropriately.

> As far as I can see, I can only use blank lines and angle brackets for 
> formatting, so I will add a whole bunch more of those, retry if they 
> will now build as part of Cygwin, and see if I can get them to look much 
> better.
> 
> If anyone has any pointers to the embedded lib doc header semantic 
> formatting conventions I would be grateful for those.

Yeah, this should be described in the documentation section of the 
'HOWTO' file, but isn't.

Briefly:

'<<' and '>>' mark up function names and code
'<[' and ']>' mark up formal parameter and variable names

There are formatting instructions for bullet points, preformatted 
monospaced text and tables, which are probably best understood by 
looking at an existing example.

In theory, you can also use any texinfo markup, but if you use anything 
outside the very limited subset currently used and understood by 
makedocbook.

Unfortunately, makedocbook relies on the prototypes being marked-up in 
quite an exact way in order to be able to massage them into the very 
detailed content model of a docbook funcsynopsis.

Re: [PATCH 0/1] newlib/libc/time/tzset_r.c(_tzset_unlocked_r): add POSIX <> quoted abbrs

[Brian Inglis]

On 2022-02-18 07:16, Jon Turney wrote:
> On 18/02/2022 03:43, Brian Inglis wrote:
>> On 2022-02-17 05:11, Corinna Vinschen wrote:
>>> On Feb 16 12:18, Brian Inglis wrote:
>>>> On 2022-02-16 01:55, Corinna Vinschen wrote:
>>>>> On Feb 15 22:38, Brian Inglis wrote:
>>>>>> 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?
>>>
>>> make info / make man?
>>
>> Thanks for the kick!
>> I finally found those targets under build64/newlib/Makefile and got 
>> errors: it looks like python {lxml,ply} need to be manually upgraded 
>> to python39-{lxml,ply} for these to work!
>>
>> Both the updated tzset info and man pages now look awful with a 
>> screenful of run on text!
> 
> That's odd since I would think the viewer should wrap appropriately.

There are now nested lists of fields and definitions which were indeed 
wrapped: into a single run on paragraph with no indentation or breaks, 
so it looks like the makedocbook docs mostly don't apply here!

>> As far as I can see, I can only use blank lines and angle brackets for 
>> formatting, so I will add a whole bunch more of those, retry if they 
>> will now build as part of Cygwin, and see if I can get them to look 
>> much better.
>>
>> If anyone has any pointers to the embedded lib doc header semantic 
>> formatting conventions I would be grateful for those.
> 
> Yeah, this should be described in the documentation section of the 
> 'HOWTO' file, but isn't.
> 
> Briefly:
> 
> '<<' and '>>' mark up function names and code
> '<[' and ']>' mark up formal parameter and variable names
> 
> There are formatting instructions for bullet points, preformatted 
> monospaced text and tables, which are probably best understood by 
> looking at an existing example.

I did get bullet lists working with "*- " prefix which marked with "- " 
but not "*", "* ", "**", "** "!
I used <[...]> and blank lines extensively to provide emphasis which 
mostly works in man pages, but as info pages convert those to uppercase, 
could not distinguish from uppercase literals, so I had to add the 
convention that those are indicated by apostrophe single quotes 'X' in 
both formats, although unnecessary in man pages, while in man format two 
adjacent variable names are concatenated, which I could not separate 
without inserting a visible character, which would be more confusing! ;^<

> In theory, you can also use any texinfo markup, but if you use anything 
> outside the very limited subset currently used and understood by 
> makedocbook.
> 
> Unfortunately, makedocbook relies on the prototypes being marked-up in 
> quite an exact way in order to be able to massage them into the very 
> detailed content model of a docbook funcsynopsis.

I'll browse the other functions to see if I can find more example 
markup, but those constructs look more like what I would expect in guile 
or m4 scripts than makedocbook, which seems natively to be closer to 
restructured text or markdown: I prefer the latter over the former!

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