All
Enclosed are the minutes of the today’s teleconference meeting
regards
Andrew
------

Minutes of the 21st January 2021 Teleconference     Austin-1096 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 21st January 2021

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

Apologies:
    Eric Ackermann, HPI, University of Potsdam

* General news 

None.


* Outstanding actions

(Please note that this section has been flushed to shorten the minutes -
to locate the previous set of outstanding actions, look to the minutes
from 13th June 2019 and earlier)

Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR 
list" OPEN
https://austingroupbugs.net/view.php?id=1254
Action: Joerg to investigate how his shell behaves.

Bug 700 - Nick to raise this issue with the C committee
Bug 713 - Nick to raise with the C committee.
Bug 739 - Nick to raise with the C committee.


* Current Business

Bug 1387: Should EAGAIN be acceptable for malloc failure?  Accepted as Marked
https://austingroupbugs.net/view.php?id=1387

This item is tagged for TC3-2008.

An interpretation is required.

Interpretation response:

The standard clearly states that implementations may use any error
number that is applicable to a particular failure, and conforming
implementations must conform to this.

Rationale:

Some implementations return EAGAIN if the resource (memory) is
temporaily unavailable. This is acceptable under the general rules
for error numbers in section 2.3 of XSH.

Notes to the Editor (not part of this interpretation):

On page 637 line 22025 (calloc() rationale), change:
    None.
to:
    See the RATIONALE for [xref to malloc()].

On page 1295 line 43167 (malloc() rationale), change:
    None.

to:
    Some implementations set errno to [EAGAIN] to signal memory
    allocation failures that might succeed if retried and [ENOMEM]
    for failures that are unlikely to ever succeed, for example due
    to configured limits. XSH section 2.3 permits this behavior,
    since when multiple error conditions described there are
    simultaneously true there is no precedence between them.

On page 1788 line 57907 (realloc() rationale), change:
    None.

to:
    See the RATIONALE for [xref to malloc()].


Bug 1388: yacc description does not say who declares yyerror() and yylex() OPEN
https://austingroupbugs.net/view.php?id=1388

We started on this item.  Comments have been recorded in
https://austingroupbugs.net/view.php?id=1388#c5205 .  Nick volunteered
to ask the Bison folks about the proposed changes.


Gettext draft.

We will return to this on a future call.

The gettext draft in the etherpad is at

https://posix.rhansen.org/p/gettext_draft
https://posix.rhansen.org/p/gettext_split

Next Steps 
----------

The next calls are on:

January 25th 2021 (Monday) 
This call will be for 60 minutes.

January 28th 2020 (Thursday)
This call will be for 90 minutes.

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

Apologies in advance:
    Don Cragun, 2021-01-25

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