The following issue has been SUBMITTED. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1874 
====================================================================== 
Reported By:                geoffclare
Assigned To:                
====================================================================== 
Project:                    1003.1(2024)/Issue8
Issue ID:                   1874
Category:                   Base Definitions and Headers
Type:                       Error
Severity:                   Editorial
Priority:                   normal
Status:                     New
Name:                       Geoff Clare 
Organization:               The Open Group 
User Reference:              
Section:                    3 
Page Number:                (many) 
Line Number:                (many) 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-11-12 17:08 UTC
Last Modified:              2024-11-12 17:08 UTC
====================================================================== 
Summary:                    ISO editors Issue 8 comment 052
Description: 
In their comment 052 on Issue 8 the ISO editors requested that any
requirements stated in definitions be removed. The Austin Group's response
was that a change would be considered for the next TC.

Where the affected requirements are already stated elsewhere they can be
deleted or changed to an informative form; otherwise they should be moved.

I have only proposed changes for cases where a definition is unambiguously
making requirements, e.g. by using "shall". There are many places where
present tense is used and I have generally assumed that these are intended
to be giving information, not making requirements.

For ease of review, where the desired action includes changes outside of
XBD chapter 3 they are stated after the definition they relate to rather
than in page and line number order.

Desired Action: 
On page 32 line 1062 section 3.10 Alias Name, change:<blockquote>In the
shell command language, a word consisting solely of alphabetics and digits
from the portable character set and any of the following characters: '!',
'%', ',', '-', '@', '_'.

Implementations may allow other characters within alias names as an
extension.

<small><b>Note:</b> The Portable Character Set is defined in detail in
[xref to 6.1].</small></blockquote>to:<blockquote>In the shell command
language, a word that can be subject to alias substitution (see [xref to
XCU 2.3.1 Alias Substitution]).</blockquote>
On XCU page 2477 line 80277 section 2.3.1 Alias Substitution,
change:<blockquote>The TOKEN is a valid alias name (see [xref to XBD
Section 3.10]).</blockquote>to:<blockquote>The TOKEN is a valid alias name.
A word consisting solely of alphabetics and digits from the portable
character set (see [xref to 6.1]) and any of the characters '!', '%', ',',
'-', '@', and '_' shall be a valid alias name. Implementations may allow
other characters within alias names as an extension.</blockquote>
On page 33 line 1094 section 3.18 Application, change:<blockquote>A
computer program that performs some desired function.

When the User Portability Utilities option is supported, requirements
placed on applications relating to the use of standard utilities shall also
apply to the actions of a user who is entering shell command language
statements into an interactive shell.</blockquote>to:<blockquote>A computer
program, or collection of programs, that performs some desired
function.</blockquote>
After page 27 line 930 section 2.2 Application Conformance, add a
paragraph:<blockquote>When the User Portability Utilities option is
supported, requirements placed on applications relating to the use of
standard utilities shall also apply to the actions of a user who is
entering shell command language statements into an interactive
shell.</blockquote>
On page 52 line 1628 section 3.146 Filename, change:<blockquote>A sequence
of bytes consisting of 1 to {NAME_MAX} bytes used to name a file. The bytes
composing the name shall not contain the <NUL> or <slash> characters. In
the context of a pathname, each filename shall be followed by a <slash> or
a <NUL> character; elsewhere, a filename followed by a <NUL> character
forms a string (but not necessarily a character
string).</blockquote>to:<blockquote>A sequence of bytes consisting of 1 to
{NAME_MAX} bytes, other than <NUL> or <slash>, used to name a file. In a
pathname, each filename is followed by a <slash> or a <NUL> character;
elsewhere, a filename followed by a <NUL> character forms a string (but not
necessarily a character string).</blockquote>
On page 55 line 1710 section 3.165 Group ID, change:<blockquote>The value
(gid_t)-1 shall not be a valid group ID, but does have a defined use in
some interfaces defined in this standard.</blockquote>to:<blockquote>The
value (gid_t)-1 does not identify a group, but does have a defined use in
some interfaces defined in this standard.</blockquote>
On page 44 line 1725 section 3.169 Hole, delete:<blockquote>Not all bytes
with the value zero need belong to a hole; however, all seekable files
shall have a virtual hole starting at the current size of the
file.</blockquote>(which is duplicated on the lseek() page).

On page 84 line 2557 section 3.363 Symbolic Constant,
change:<blockquote>Unless stated otherwise, the following shall apply to
every symbolic constant: <ul>
<li>It expands to a compile-time constant expression with an integer
type.</li>
<li>It may be defined as another type of constant--e.g., an enumeration
constant--as well as being a macro.</li>
<li>It need not be usable in <b>#if</b> preprocessing directives.</li>
</ul></blockquote>to:<blockquote><small><b>Note:</b> Additional
requirements apply to symbolic constants over and above those for other
object-like macros. See [xref to XSH 2.1.2 Use and Implementation of
Macros].</small></blockquote>
After XSH page 496 line 17408 section 2.1.2, add:<blockquote>For every
macro that is a symbolic constant, in addition the following shall apply
unless explicitly stated otherwise: <ul>
<li>It expands to a compile-time constant expression with an integer
type.</li>
<li>It may be defined as another type of constant--e.g., an enumeration
constant--as well as being a macro.</li>
<li>It need not be usable in <b>#if</b> preprocessing directives.</li>
</ul></blockquote>
On page 88 line 2672 section 3.389, change:<blockquote>The value shall be
unique across all threads in a process, regardless of whether the thread
is:</blockquote>to:<blockquote>The value is unique across all threads in a
process (see [xref to 2.9.2 Thread IDs]).</blockquote>and move the
remaining lines (2674-2683), minus the final sentence of the small-font
note (ending "are defined in detail in the System Interfaces volume of
POSIX.1-2024"), to the location indicated in the next change.

On XSH page 538 line 19191 section 2.9.2 Thread IDs, after:<blockquote>The
effect of calling any of the functions defined in this volume of
POSIX.1-2024 and passing as an argument the thread ID of a thread from
another process is unspecified.</blockquote>add:<blockquote>The value of a
thread ID shall be unique across all threads in a process, regardless of
whether the thread is:</blockquote>followed by the moved lines from the
previous change.

On page 89 line 2702-2709 section 3.393 Thread-Safe, move the entire
definition, minus the second sentence ("Each function defined in the System
Interfaces volume of POSIX.1-2024 is thread-safe unless explicitly stated
otherwise.") to the beginning of XSH 2.9.1 Thread-Safety at page 537 line
19147.

On page 89 line 2702 section 3.393 Thread-Safe, insert a new
definition:<blockquote>A thread-safe function is one that avoids data races
with other calls to the same function, and with calls to any other
thread-safe functions, by multiple threads.

<small><b>Note:</b> Thread-Safety is defined in detail in [xref to XSH
2.9.1].</small></blockquote>
On page 91 line 2770 section 3.408 User ID, change:<blockquote>The value
(uid_t)-1 shall not be a valid user ID, but does have a defined use in some
interfaces defined in this standard.</blockquote>to:<blockquote>The value
(uid_t)-1 does not identify a user, but does have a defined use in some
interfaces defined in this standard.</blockquote>

====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-11-12 17:08 geoffclare     New Issue                                    
2024-11-12 17:08 geoffclare     Name                      => Geoff Clare     
2024-11-12 17:08 geoffclare     Organization              => The Open Group  
2024-11-12 17:08 geoffclare     Section                   => 3               
2024-11-12 17:08 geoffclare     Page Number               => (many)          
2024-11-12 17:08 geoffclare     Line Number               => (many)          
2024-11-12 17:08 geoffclare     Interp Status             => ---             
======================================================================


  • [1003.1(20... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003... Austin Group Issue Tracker via austin-group-l at The Open Group

Reply via email to