RE: can [[:digit:]] match something other than 0123456789?

[Garrett Wollman]

< said:

> Also, my feeling is that [[:digit:]] should match just the digits
> that are actually relevant for that locale, e.g., just "western"
> digits for en_GB.  And fractions and superscripts are not digits.

Implementations often use the same character definitions for all
locales using the same character set -- such as the Unicode character
data file, for Unicode-based locales.  I think changing this may be a
tough sell for many implementers, just given the sheer number of
characters (and bikeshed-painting debates about which particular
character class or collation element should include which characters
in which locales would not be welcome).

-GAWollman

[1003.1(2016)/Issue7+TC2 0001195]: main() should be main(void)

[Austin Group Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://austingroupbugs.net/view.php?id=1195 
== 
Reported By:eblake
Assigned To:
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1195
Category:   System Interfaces
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: New
Name:   Eric Blake 
Organization:   Red Hat 
User Reference: main 
Section:pthread_mutexattr_destroy 
Page Number:1683 
Line Number:54891 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2018-05-24 16:30 UTC
Last Modified:  2018-05-24 16:30 UTC
== 
Summary:main() should be main(void)
Description: 
The standard states that both:
int main(void)
int main(int, char**)
are acceptable prototypes for the main entry-point, but the K var-arg
style:
main()
is not.  We should be consistent in our examples.
Desired Action: 
Change 'main()' to 'main(void)' in these locations:
P1683 L54891 pthread_mutexattr_destroy
P1684 L54904 pthread_mutexattr_destroy
P1684 L54918 pthread_mutexattr_destroy
P1953 L62919 sigaction
P2568 L83198 cflow
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2018-05-24 16:30 eblake New Issue
2018-05-24 16:30 eblake Name  => Eric Blake  
2018-05-24 16:30 eblake Organization  => Red Hat 
2018-05-24 16:30 eblake User Reference=> main
2018-05-24 16:30 eblake Section   =>
pthread_mutexattr_destroy
2018-05-24 16:30 eblake Page Number   => 1683
2018-05-24 16:30 eblake Line Number   => 54891   
2018-05-24 16:30 eblake Interp Status => --- 
==

[1003.1(2016)/Issue7+TC2 0001107]: *rand48(): We don't explain how the LCG state is 'transformed into the returned value'

[Austin Group Bug Tracker]

The following issue has been RESOLVED. 
== 
http://austingroupbugs.net/view.php?id=1107 
== 
Reported By:EdSchouten
Assigned To:ajosey
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1107
Category:   Base Definitions and Headers
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Resolved
Name:   Ed Schouten 
Organization:   Nuxi 
User Reference:  
Section:*rand48() 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text:http://austingroupbugs.net/view.php?id=1107#c4040 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2016-12-08 15:09 UTC
Last Modified:  2018-05-24 16:09 UTC
== 
Summary:*rand48(): We don't explain how the LCG state is
'transformed into the returned value'
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-12-08 15:09 EdSchouten New Issue
2016-12-08 15:09 EdSchouten Status   New => Under Review 
2016-12-08 15:09 EdSchouten Assigned To   => ajosey  
2016-12-08 15:09 EdSchouten File Added: rand48-test-vectors.c   

2016-12-08 15:09 EdSchouten Name  => Ed Schouten 
2016-12-08 15:09 EdSchouten Organization  => Nuxi
2016-12-08 15:09 EdSchouten Section   => *rand48()   
2016-12-08 15:09 EdSchouten Page Number   => -   
2016-12-08 15:09 EdSchouten Line Number   => -   
2016-12-08 15:24 geoffclare Project  1003.1(2008)/Issue 7 =>
1003.1(2016)/Issue7+TC2
2018-05-24 16:05 geoffclare Note Added: 0004040  
2018-05-24 16:09 geoffclare Interp Status => --- 
2018-05-24 16:09 geoffclare Final Accepted Text   =>
http://austingroupbugs.net/view.php?id=1107#c4040
2018-05-24 16:09 geoffclare Status   Under Review =>
Resolved
2018-05-24 16:09 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2016)/Issue7+TC2 0001107]: *rand48(): We don't explain how the LCG state is 'transformed into the returned value'

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1107 
== 
Reported By:EdSchouten
Assigned To:ajosey
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1107
Category:   Base Definitions and Headers
Type:   Omission
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Ed Schouten 
Organization:   Nuxi 
User Reference:  
Section:*rand48() 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-12-08 15:09 UTC
Last Modified:  2018-05-24 16:05 UTC
== 
Summary:*rand48(): We don't explain how the LCG state is
'transformed into the returned value'
== 

-- 
 (0004040) geoffclare (manager) - 2018-05-24 16:05
 http://austingroupbugs.net/view.php?id=1107#c4040 
-- 
Replace this sentence on P749, L25537-25539:Then the
appropriate number of bits, according to the type of data item to be
returned, are copied from the high-order (leftmost) bits of Xi
and transformed into the returned
value.with:Xi is then converted to the
return value as follows:

- For drand48() and erand48() the value shall be
2-48 times Xi.
- For jrand48() and mrand48() the value shall be the largest
integer not greater than 2-16 times Xi.
- For lrand48() and nrand48() the value shall be the largest
integer not greater than 2-17 times Xi.
Change the EXAMPLES section on P750, L25571
from:None.to:The following program
tests that the required pseudo-random number generator is used by these
functions.
and then add the contents of the file rand48-test-vectors.c attached to
this bug. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-12-08 15:09 EdSchouten New Issue
2016-12-08 15:09 EdSchouten Status   New => Under Review 
2016-12-08 15:09 EdSchouten Assigned To   => ajosey  
2016-12-08 15:09 EdSchouten File Added: rand48-test-vectors.c   

2016-12-08 15:09 EdSchouten Name  => Ed Schouten 
2016-12-08 15:09 EdSchouten Organization  => Nuxi
2016-12-08 15:09 EdSchouten Section   => *rand48()   
2016-12-08 15:09 EdSchouten Page Number   => -   
2016-12-08 15:09 EdSchouten Line Number   => -   
2016-12-08 15:24 geoffclare Project  1003.1(2008)/Issue 7 =>
1003.1(2016)/Issue7+TC2
2018-05-24 16:05 geoffclare Note Added: 0004040  
==

[1003.1(2016)/Issue7+TC2 0001106]: *rand48(): Should this use uint16_t instead of unsigned short?

[Austin Group Bug Tracker]

The following issue has been CLOSED. 
== 
http://austingroupbugs.net/view.php?id=1106 
== 
Reported By:EdSchouten
Assigned To:ajosey
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1106
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Ed Schouten 
Organization:   Nuxi 
User Reference:  
Section: 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
Resolution: Rejected
Fixed in Version:   
== 
Date Submitted: 2016-12-07 14:11 UTC
Last Modified:  2018-05-24 15:28 UTC
== 
Summary:*rand48(): Should this use uint16_t instead of
unsigned short?
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-12-07 14:11 EdSchouten New Issue
2016-12-07 14:11 EdSchouten Status   New => Under Review 
2016-12-07 14:11 EdSchouten Assigned To   => ajosey  
2016-12-07 14:11 EdSchouten Name  => Ed Schouten 
2016-12-07 14:11 EdSchouten Organization  => Nuxi
2016-12-07 14:11 EdSchouten Section   =>   
2016-12-07 14:11 EdSchouten Page Number   => -   
2016-12-07 14:11 EdSchouten Line Number   => -   
2016-12-08 15:23 geoffclare Project  1003.1(2008)/Issue 7 =>
1003.1(2016)/Issue7+TC2
2018-05-24 15:27 Don Cragun Note Added: 0004039  
2018-05-24 15:28 Don Cragun Interp Status => --- 
2018-05-24 15:28 Don Cragun Status   Under Review => Closed
2018-05-24 15:28 Don Cragun Resolution   Open => Rejected
==

[1003.1(2016)/Issue7+TC2 0001106]: *rand48(): Should this use uint16_t instead of unsigned short?

[Austin Group Bug Tracker]

A NOTE has been added to this issue. 
== 
http://austingroupbugs.net/view.php?id=1106 
== 
Reported By:EdSchouten
Assigned To:ajosey
== 
Project:1003.1(2016)/Issue7+TC2
Issue ID:   1106
Category:   Base Definitions and Headers
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: Under Review
Name:   Ed Schouten 
Organization:   Nuxi 
User Reference:  
Section: 
Page Number:- 
Line Number:- 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2016-12-07 14:11 UTC
Last Modified:  2018-05-24 15:27 UTC
== 
Summary:*rand48(): Should this use uint16_t instead of
unsigned short?
== 

-- 
 (0004039) Don Cragun (manager) - 2018-05-24 15:27
 http://austingroupbugs.net/view.php?id=1106#c4039 
-- 
The standard permits uint16_t and unsigned short to be distinct types, even
if they 
have the same bitwise layout; on such an implementation, changing the
signature 
would cause a compilation error on existing code due to type mismatch. 
These 
interfaces are intended for backwards compatibility, not for use in new
code.  
Since changing the signature could break existing code, we have decided to
reject 
this change request. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-12-07 14:11 EdSchouten New Issue
2016-12-07 14:11 EdSchouten Status   New => Under Review 
2016-12-07 14:11 EdSchouten Assigned To   => ajosey  
2016-12-07 14:11 EdSchouten Name  => Ed Schouten 
2016-12-07 14:11 EdSchouten Organization  => Nuxi
2016-12-07 14:11 EdSchouten Section   =>   
2016-12-07 14:11 EdSchouten Page Number   => -   
2016-12-07 14:11 EdSchouten Line Number   => -   
2016-12-08 15:23 geoffclare Project  1003.1(2008)/Issue 7 =>
1003.1(2016)/Issue7+TC2
2018-05-24 15:27 Don Cragun Note Added: 0004039  
==

Austin Group teleconference +1-888-426-6840 PIN: 2115756

[Single UNIX Specification]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:5b06d90024...@opengroup.org
DTSTAMP:20180524T152344Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20180524T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1-888-426-6840 PIN: 2115756\nDate/Time: 31-May-2018 at 11:00 
 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.opengro
 up.org/platform/single_unix_specification/events.php\n\n 	\n\n** All calls 
 are anchored on US time **\n\nTopic: Austin Group teleconference\n
 ---\nAudio conference informat
 ion\n---\nCall-in toll
  free number (US/Canada): +1-888-426-6840\nParticipant PIN: 2115756.\n\nAl
 l Austin Group participants are most welcome to join the call.\nThe call w
 ill last for 1.5 hours .\nThis call is handling defect report processing.
 \n\nAn etherpad is usually up for a meeting\, with a URL using the date fo
 rmat as below:\n\nhttp://posix.rhansen.org/p/201x-mm-dd\nusername=posix pa
 ssword=2115756#\n\nAdditional Call-in numbers:\nGermany Ca
 ller Paid0-69-2443-2290\nGermany Toll-Free
0800-000-1018\nUnited Kingdom   Caller Paid   0-20-
 30596451\nUnited Kingdom   Toll-Free  0800-368-0638\nUSA  
Caller Paid   215-861-6239\nUSA
 Toll-Free   888-426-6840\nDenmark 
 Caller Paid32711870\nDenmark Toll-Free
80-717000\nCzech Republic  Caller Paid 2-390163
 53\nCzech Republic  Toll-Free   800-143-484\nCall-in n
 umbers for other countries are available on request\n\nBug reports are ava
 ilable at:\nhttp://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20180531T11
DURATION:PT1H30M0S
LAST-MODIFIED:20180524T112344Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1-888-426-6840 PIN: 2115756
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

Re: can [[:digit:]] match something other than 0123456789?

[Joerg Schilling]

Stephane CHAZELAS  wrote:

> Is that a POSIX invention (the [a-z] based on collation) by the
> way, or does it come from implementations that already existed
> at the time?

Around 1993, all major UNIX platforms used the same code that was derived from 
IBM.

Maybe this is the background...


Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

RE: can [[:digit:]] match something other than 0123456789?

[Schwarz, Konrad]

> -Original Message-
> From: Stephane Chazelas [mailto:stephane.chaze...@gmail.com]
> Sent: Sunday, May 20, 2018 10:43 PM
> To: Geoff Clare
> Cc: austin-group-l@opengroup.org
> Subject: Re: can [[:digit:]] match something other than 0123456789?
> 

> Note that having [x-y] be based on collation order would mean that things 
> like [a-z]
> would also match on uppercase letters in the latin script in locales where 
> case is
> not considered in the first weight for sorting (as is typical for English 
> locales for
> instance).
> 
> 
> Now, in a en_GB.UTF-8 locale on GNU/Linux (here ubuntu 16.04) for instance, 
> both
> bash's and ksh93's [0-9] matches on at least
> 142 different characters (see below). That matches on 0123456789 but also 
> digits 0
> (sometime 1) to 8 (sometimes 9 like for U+0669 which sorts the same as 9 
> there!)
> in other scripts, and some other random decimal digits, and some non-digits 
> and
> is far from including all the plethora of other decimal digits in Unicode.
> (unicode --max 0 --regexp 
> 'digit.(one|two|three|four|five|six|seven|eight|nine)\b' |
> grep -c '^U+'
> retuns 696 with an old version of unicode, and that doesn't even include 
> things like
> roman numerals).

I'd find [0-9] matching on just "western" digits and [[:digit:]] matching
on the locale's digits the most natural solution.  If someone wanted to match
on Devanagari or whatever digits, she could simply list them in the bracket 
expression, rather than using
"western" digits.  If [0-9] is understood to be [[:digit:]], how could one 
differentiate between "western"
and, say, Devanagari digits (other than listing them each explicitly, 
[0123456789], as Stephane has done)?

Same goes for [a-z]: these should match (or should be) the Roman letters, not 
alphabetic characters
in general.

Also, my feeling is that [[:digit:]] should match just the digits that are 
actually relevant for that locale, e.g.,
just "western" digits for en_GB.  And fractions and superscripts are not digits.

If you really want to match any digit in any language, you could add a 
"Unicode" locale or perhaps region.