All
Enclosed are the minutes from yesterday’s meeting
regards
Andrew
====
Minutes of the 26th January 2023 Teleconference    Austin-1286 Page 1 of 1
Submitted by Andrew Josey, The Open Group.         27th January 2023

Attendees:
    Don Cragun, IEEE PASC OR
    Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
    Mark Ziegast, SHware Systems Dev.
    Andrew Josey, The Open Group
    Geoff Clare, The Open Group
    Eric Blake, Red Hat, The Open Group OR

Apologies
    Eric Ackermann
    Tom Thompson, IEEE

* General news

PDF release candidates of Draft 3 are now complete. Andrew
has sent the frontmatter to Tom at IEEE to see if any
updates are needed. This could save time with the MEC.

Andrew has written to Joe Gwinn at PASC to request a vote of the PASC SEC to
approve the draft going into ballot.
(It looks like we can simply request a vote).

On the matter of  why Fedora dropped the POSIX man pages
this seems to relate to the permissions text included in the Linux man pages
project which varies from what we grant to them.


* Carried Forward

This section trimmed -- see Austin/1264

Bug 1406: clarification of SEEK_END when current pointer doesn't match buffer 
size OPEN
https://austingroupbugs.net/view.php?id=1406 

Actions carried forward:

ACTION: Andrew to contact Rich Felker (dalias) and Alan Coopersmith (Solaris) 
for feedback. 
Completed
ACTION: Eric B to contact glibc folks.


Bug 1616: Standardize mktemp utility OPEN
https://austingroupbugs.net/view.php?id=1616

We will need a sponsor; it is not suitable for inclusion in Issue 8.
ACTION: Eric to ask The Open Group to sponsor adding the mktemp utility
(for Issue 9).

Bug 1291: Add method to obtain pthread attributes OPEN
https://austingroupbugs.net/view.php?id=1291

Needs additional details and sponsor for Issue 9

Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in 
filenames  OPEN
http://austingroupbugs.net/view.php?id=251

(brought forward)
Don has an action to produce a proposal.

Bug 1622: Standardize getpeereid function OPEN
https://austingroupbugs.net/view.php?id=1622

Action: Eric B to ask The Open Group if they are willing to sponsor this 
function for Issue 9.

* Current Business

The ISO C meeting was in progress and the group discussed issues
arising from the ballot resolutions occurring in that meeting.

Bug 728 Restrictions on signal handlers are both excessive and insufficient OPEN
https://austingroupbugs.net/view.php?id=728 

A note was added to this bug:

In the January 2023 ballot resolution meeting, WG14 decided not to
make any change to the signal handler requirements in C23. This
means we are free to change this as we please (with CX shading)
without worrying about the potential for a mis-match with an
equivalent change in C23.

A useful piece of feedback from them is that we need to be careful
about the phrase "const-qualified objects". If a modifiable object
of type T is accessed via a pointer to const T, this could be
interpreted as accessing a const-qualified object, but obviously
should not be allowed. I suggest the text should say that access
to "non-modifiable objects" is allowed and give as examples: string
literals, objects that were defined with a const-qualified type,
and objects in memory that was mapped read-only.

Issue 8 will have the definition of "happens before" from C17, so
we could use that to add something about sequencing. Perhaps something
along the lines of "the previous modification (if any) to the object
happens before the signal handler is called and the return from the
signal handler happens before the next modification (if any) to the
object".

Note that there will be changes in this area in draft 3 (talking
about lock-free atomic objects) so we should wait for draft 3 before
working on wording changes.


Bug 708 Make mblen, mbtowc, and wctomb thread-safe for alignment with C11 OPEN
https://austingroupbugs.net/view.php?id=708 

A note was added:
See https://austingroupbugs.net/view.php?id=708#c6139

Bug 739: CX requirements for strftime seem to conflict with ISO C Accept as 
Marked.
https://austingroupbugs.net/view.php?id=739

This is tagged for TC3-2008

Change:
    Equivalent to %[CX]+4[/CX]Y-%m-%d if no flag and no minimum
    field width are specified.

to:
    Equivalent to %Y-%m-%d if no flag and no minimum field width
    are specified. (For years between 1000 and 9999 inclusive this
    provides the ISO 8601:2004 complete representation, extended
    format date representation of a specific day.)


On 2018 edition page 2049 line 65723 section strftime() APPLICATION USAGE, 
after:
    These two forms can be produced with the '0' flag and a minimum
    field width options using the conversions specifications %04Y
    and %01Y, respectively.
add:
    Similarly, because %Y is part of %F, field widths of 10 and 7
    (%010F, %07F), respectively, produce the same effect in the
    year portion of the %F conversion result.


On 2018 edition page 2049 line 65725 section strftime() APPLICATION USAGE, 
change:
    For years in the range [0001,9999], POSIX.1-2017 requires that
    the output produced match the ISO 8601:2004 standard complete
    representation extended format (YYYY-MM-DD) and for years outside
    of this range produce output that matches the ISO 8601:2004
    standard expanded representation extended format
    (<+/-><Underline>Y</Underline>YYYY-MM-DD).
to:
    For years in the range [1000,9999], POSIX.1-2017 requires that
    the output produced match the ISO 8601:2004 standard complete
    representation extended format (YYYY-MM-DD) and for years greater
    than 9999 produce output that matches the ISO 8601:2004 standard
    expanded representation extended format
    (<+/-><Underline>Y</Underline>YYYY-MM-DD). For years less than
    1000, %F is not required to produce an ISO 8601:2004 format
    when used without specifying at least a minimum field width.
    As stated above, some implementations pad %Y conversions with
    zeros to four digits, in which case %F produces an ISO 8601:2004
    format; other implementations do not pad %Y with zeros, in which
    case %F does not produce an ISO 8601:2004 format .




We will start here next time.

Next Steps
----------
The next calls are on:
   Mon 2023-01-30 (general bugs)
   Thu 2023-02-02 (general bugs)

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Apologies in advance
        Geoff Clare  2023-01-30, 2023-02-02
        Andrew Josey 2023-01-30 (partial)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)

--------
Andrew Josey                    The Open Group
Austin Group Chair          
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub&listid=2481





Reply via email to