Minutes of the 28th January 2021 Teleconference     Austin-1098 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 28th January 2021

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

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 1388: yacc description does not say who declares yyerror() and yylex() Accepted as Marked
https://austingroupbugs.net/view.php?id=1388

This item is tagged for Issue 8

On page 3456 line 116732 section yacc (Code File), change:
    It also shall contain a copy of the #define statements in the header file.

to:
    It also shall contain a copy of the #define statements in the
    header file, prior to any code copied from semantic actions in
    grammar, and the following function prototypes for the yyerror(),
    yylex(), and yyparse() functions, after any code copied from
    within <tt>%{</tt> and <tt>%}</tt> in the declarations section
    in grammar and before any code copied from semantic actions in
    grammar:

    void yyerror(const char *);
    int yylex(void);
    int yyparse(void);

    The declarations of yyerror() and yylex() shall be protected
    by #ifndef or #if preprocessor statements such that each is
    only visible if a preprocessor macro with the name yyerror or
    yylex, respectively, is not already defined, where the yy in
    the macro names is replaced by sym_prefix if the -p sym_prefix
    option is used.

On page 3456 line 116734 section yacc (Code File), add a new paragraph:
    The code file shall not contain a declaration of the main()
    function, unless one is present within <tt>%{</tt> and <tt>%}</tt>
    in the declarations section in grammar.

On page 3456 line 116739 section yacc (Header File), add a new sentence:
    The header file may also declare the yyparse() function, using
    a function prototype. It shall not declare the yyerror() and
    yylex() functions.

On page 3465 line 117139 section yacc (Yacc Library), change:
    int yyerror(const char *s)

to:
    void yyerror(const char *s)


On page 3467 line 117217 section yacc (APPLICATION USAGE), add new paragraph:
    If yyerror() and yylex() are not defined within <tt>%{</tt> and
    <tt>%}</tt> in the declarations section as functions or macros,
    nor in the programs section as functions, recommended practice
    is to declare them as functions in a separate header file and
    include that file in the declarations section, followed by
    <tt>#define yyerror yyerror</tt> and <tt>#define yylex yylex</tt>.
    This lets the separate header file be the definitive API for
    all code defining or using these functions.

On page 3467 line 117239 section yacc (EXAMPLES), change:
    int yyerror(const char *msg)

to:
    void yyerror(const char *msg)

On page 3469 line 117335 section yacc (RATIONALE), add new paragraphs:
    Earlier versions of this standard did not require the code file
    created by yacc to contain declarations of yyerror(), yylex(),
    and yyparse(). This meant that portable applications that did
    not define them had to declare them in the grammar file, to
    ensure they would not be diagnosed by the compiler as being
    called without being declared, but this was not stated in those
    versions of the standard either. The standard developers decided
    it was preferable for yacc to include the declarations in the
    code file and this is now a requirement. However, the declarations
    of yyerror() and yylex() are only visible if a macro of the
    same name is not defined, which provides application writers
    with a way to suppress the declaration if desired (for example,
    in order to provide their own declaration that would conflict
    with the one written by yacc()). These functions are not declared
    in the header file because a macro definition in the declaration
    section would not be be able to suppress them there.

    Earlier versions of this standard were also silent about a
    declaration of main(). However, the equivalent solution was not
    adopted because a declaration of main() would only be needed
    if it is called recursively by an application. Although in
    theory an application could call the yacc library version of
    main() from code in a grammar file, it is questionable why any
    application (other than a test suite) would do so, in particular
    because that version of main() does not accept any arguments
    and it calls exit()—it does not return—and therefore is of
    little use recursively. An application that includes its own
    definition of main() could call it recursively, but can reasonably
    be expected to ensure it does not call main() without previously
    defining or declaring it. An additional complication is that
    main() has multiple different allowed prototypes. The standard
    developers decided the simplest solution was to disallow yacc
    from providing a declaration of main() in the code file.


Bug #1389:  Shell command search procedure is incorrect Duplicate of 854
https://austingroupbugs.net/view.php?id=1389

Bug #1445: Update "special built-in" to match changes from bug #854 Accepted
https://austingroupbugs.net/view.php?id=1445

This item is tagged for Issue 8

Bug #1390: No method to invoke a non-standard built-in utility Rejected
https://austingroupbugs.net/view.php?id=1390 

"The standard as currently written provides no mechanism to allow
such non-standard built-in utilities to be invoked."

This was solved in Issue 8 draft 1 by allowing implementations to
add to the list of intrinsic utilities. See XCU 1.7 (P2268 L73117)
in the draft: "Whether any additional utility is considered an
intrinsic utility is implementation-defined." All the implementation
needs to do is document the additions.

This practice is not recommended (through the use of "should not" on L73119) but is allowed. 

Bug #1391: Unclear language in specification of utilities implemented as functions Accepted as Marked
https://austingroupbugs.net/view.php?id=1391

This item is tagged for TC3-2008.

Change:

    If the implementation has provided a standard utility in the
    form of a function, it shall not be recognized at this point.

to:

    If the implementation has provided a standard utility in the
    form of a function, and that function definition still exists
    (i.e. has not been rem

Bug #1392: find(1): clarify whether -perm ops - and + should follow chmod OPEN
https://austingroupbugs.net/view.php?id=1392

We started this item and will continue next time


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:

February 1st 2021 (Monday) 
This call will be for 60 minutes.

February 4th 2020 (Thursday)
This call will be for 90 minutes.

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

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)