All
Enclosed are the minutes of yesterday’s meeting
regards
Andrew
------------
Minutes of the 11th April 2024 Teleconference Austin-1398 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 12th April 2024
Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group (partial)
Eric Blake, Red Hat, The Open Group OR
Geoff Clare, The Open Group
Apologies
Eric Ackermann, CISPA
Mark Ziegast, SHware Systems Dev
* General news
Action carried forward:Andrew took an action to reach out to Paul Eggert to
find out when
he can next attend.
Andrew closed this action after the meeting.
* Current Business
1797: strftime "%s" should be able to examine tm_gmtoff OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1797
We will continue this item next time that Paul is available (expected in April).
Bug 1808: Add option -a to getconf utility Accepted as Marked
https://austingroupbugs.net/view.php?id=1808
This item is tagged for issue9.
After page 2831 line 93192 section getconf SYNOPSIS, add:
getconf -a [-v specification] [pathname]
After page 2831 line 93197 section getconf DESCRIPTION, add:
If the -a option is specified, the getconf utility shall write
to the standard output the names and values of all valid
configuration variables; that is, every system_var operand and
every path_var operand that the utility accepts, together with
the values of the variables specified by those operands. For
path_var operands the value written shall be the value of the
variable for the path specified by the pathname operand, if
present; if no pathname is provided, it is implementation-defined
whether the value is for the current working directory (.) or
the root directory (/).
On page 2831 line 93204 section getconf OPTIONS, change:
The following option shall be supported:
to:
The following options shall be supported:
-a
Write the names and values of all valid configuration variables.
After page 2833 line 93307 section getconf STDOUT, add these new paragraphs:
If the -a option is specified, the name of each valid configuration
variable and information about the variable shall be written
in the following format:
"%s: %s\n", <name>, <info_string>
where <info_string> is the information string that would be
written (without the terminating <newline>) for the variable
if specified as an operand, as described below.
The remainder of this section describes the behavior if the -a
option is not specified.
On page 2834 line 93327 section getconf EXIT STATUS, change:
The specified variable is valid and information about its current
state was written successfully.
to:
The -a option was specified and the names of all valid configuration
variables were written successfully together with information
about each variable's current state, or the -a option was not
specified, the specified variable is valid, and information
about its current state was written successfully.
On page 2834 line 93333 section getconf APPLICATION USAGE, change:
None.
to:
Since the value of a configuration variable obtained from
confstr() may include <newline> characters, the output when the
-a option is specified cannot be assumed to contain one name
and value per line. Applications can use the presence of a
<colon> at the end of the variable name as a means to distinguish
names from parts of values that follow a <newline>; however,
it is possible (although unlikely) for a multi-line value to
match this and it is recommended that applications needing to
extract a list of valid variable names should confirm their
validity by checking whether getconf accepts them as either a
system_var or path_var operand.
After page 2835 line 93364 section getconf RATIONALE, add a new paragraph:
Historically the GNU implementation of getconf -a did not output
a <colon> after each variable name, whereas other implementations
did. The standard developers decided to require the <colon> in
order to help applications and users distinguish variable names
from parts of values that follow a <newline>. In some implementations
the use of -v with -a was undocumented but supported; in others
it was not supported, but it was felt to be a useful feature
that would be simple to provide.
Bug 1809: close() guidance to use fclose() should also discuss fdopen()
Accepted as Marked
https://austingroupbugs.net/view.php?id=1809
This item is tagged for TC1-2024.
Change:
An application that had used the stdio routine fopen() to open
a file should use the corresponding fclose() routine rather
than close(). Once a file is closed, the file descriptor no
longer exists, since the integer corresponding to it no longer
refers to a file.
to:
If the file descriptor is associated with a standard I/O stream
(for example, if the file descriptor was obtained by calling
fileno() on a stream, or if an associated stream was created
using fdopen()), the file descriptor should be closed using
fclose() on the associated stream (or pclose() if the stream
was opened using popen()) instead of calling close() or
posix_close() on the file descriptor. Once a file descriptor
is closed, the integer corresponding to it no longer refers to
a file. However, the same integer can be allocated on a subsequent
file open and would then become associated with the stream if
the stream has not been closed.
If the file descriptor is associated with a directory stream
(for example, if the file descriptor was obtained by calling
dirfd() on a directory stream, or if a directory stream was
created using fdopendir()), the file descriptor should be closed
using closedir() on the associated directory stream instead of
calling close() or posix_close() on the file descriptor.
Bug 1810: fdopen() can only be used once per file descriptor OPEN
https://austingroupbugs.net/view.php?id=1810
We will continue on this item next time.
Next Steps
----------
The next call is on:
Mon 2024-04-15 (WEBEX meeting - general bugs)
Thu 2024-04-18 (WEBEX meeting - general bugs)
Apologies in advance:
2024-04-22 - 2024-04-25 Nick Stoughton
2024-04-22 Geoff Clare
The calls are 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)
--------
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
