The following issue has been SUBMITTED.
======================================================================
https://austingroupbugs.net/view.php?id=1878
======================================================================
Reported By: geoffclare
Assigned To:
======================================================================
Project: 1003.1(2024)/Issue8
Issue ID: 1878
Category: Base Definitions and Headers
Type: Error
Severity: Editorial
Priority: normal
Status: New
Name: Geoff Clare
Organization: The Open Group
User Reference:
Section: (many)
Page Number: (many)
Line Number: (many)
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2024-11-19 15:10 UTC
Last Modified: 2024-11-19 15:10 UTC
======================================================================
Summary: ISO editors Issue 8 comments 061+072
Description:
In their comments 061 and 072 on Issue 8 the ISO editors requested that
uses of "might" be changed to other wording. The Austin Group's response
was that a change would be considered for the next TC.
So far I have only considered uses in normative text and in small-font
notes within normative text. There are too many in other informative text
to address them all in a "quick" TC.
Some of the uses came from C17, and in those cases the proposed new wording
is taken from the latest C2Y draft.
Desired Action:
On page 7 line 147 section 1.8 Portability, change:<blockquote>describe
functionality that might not be fully portable to systems meeting the
requirements for POSIX conformance</blockquote>to:<blockquote>describe
functionality that is not fully portable to all systems meeting the
requirements for POSIX conformance</blockquote>
On page 25 line 833 section 2.1.6 Options, change:<blockquote>For example,
an old application binary might be run on a newer implementation to which
support for the option has been added.</blockquote>to:<blockquote>For
example, an old application binary could be run on a newer implementation
to which support for the option has been added.</blockquote>
On page 25 line 841 section 2.1.6 Options, change:<blockquote>Option might
or might not be supported at runtime.
The implementation advertises at compile time (by defining the constant in
<b><unistd.h></b> with value zero) that the option is supported for
compilation and might or might not be supported at
runtime.</blockquote>to:<blockquote>Option supported for compilation and
possibly supported at runtime.
The implementation advertises at compile time (by defining the constant in
<b><unistd.h></b> with value zero) that the option is supported for
compilation and is possibly supported at runtime.</blockquote>
On page 39 line 1255 section 3.55 Byte, change:<blockquote>The definition
of byte from the ISO C standard is broader than the above and might
accommodate hardware architectures with different sized addressable units
than octets.</blockquote>to:<blockquote>The definition of byte from the ISO
C standard is broader than the above and accommodates hardware
architectures with different sized addressable units than
octets.</blockquote>
On page 44 line 1417 section 3.90 CPU Time, change:<blockquote>With this
definition the sum of all the execution times of all the threads in a
process might not equal the process execution
time</blockquote>to:<blockquote>With this definition it is possible that
the sum of all the execution times of all the threads in a process does not
equal the process execution time</blockquote>
On page 68 line 2091 section 3.254 Pathname, change:<blockquote>otherwise,
the pathname might only be a string (rather than a character
string).</blockquote>to:<blockquote>otherwise, it is possible that the
pathname is only a string (rather than a character string).</blockquote>
On page 96 line 2888 section 4.3 Default Initialization,
change:<blockquote>a structure initialized using { 0 } might not
<i>memcmp</i>() as equal to</blockquote>to:<blockquote>it is possible that
a structure initialized using { 0 } does not <i>memcmp</i>() as equal
to</blockquote>
On page 99 line 3019 section 4.13 Host and Network Byte Orders,
change:<blockquote>Bits might not be allocated to bytes in any obvious
order at all.</blockquote>to:<blockquote>It is possible that bits are not
be allocated to bytes in any obvious order at all.</blockquote>
On page 102 line 3125 section 4.15.1.1 Data Races, change:<blockquote>The
set of side effects from which a given evaluation might take its value is
also restricted</blockquote>to:<blockquote>The set of side effects from
which a given evaluation can take its value is also
restricted</blockquote>
On page 104 line 3209 section 4.15.2 Memory Synchronization,
change:<blockquote>no thread of control can read or modify a memory
location while another thread of control might be modifying
it.</blockquote>to:<blockquote>no thread of control can read or modify a
memory location while another thread of control could be modifying
it.</blockquote>
On page 110 line 3473 section 4.24 Treatment of NaN Arguments ...,
change:<blockquote>The function might never see the signaling NaN, since it
might trigger when the arguments are</blockquote>to:<blockquote>It is
possible that the function never sees the signaling NaN, since it could
trigger when the arguments are</blockquote>
On page 111 line 3483 section 4.25 Utility, change:<blockquote>such as
might be produced by a compiler</blockquote>to:<blockquote>such as could be
produced by a compiler</blockquote>
On page 131 line 4250 section 7.3.1 LC_CTYPE, change:<blockquote>it might
not be possible for conforming applications to work
properly.</blockquote>to:<blockquote>it is possible that conforming
applications will not work properly.</blockquote>
On page 171 line 6020 section 8.2 Internationalization Variables,
change:<blockquote>directory names that might be used in <i>NLSPATH</i>
should not include a <colon>
character.</blockquote>to:<blockquote>directory names that could be used in
<i>NLSPATH</i> should not include a <colon> character.</blockquote>
On page 175 line 6185 section 8.3 Other Environment Variables,
change:<blockquote>directory names that might be used in <i>PATH</i> should
not include a <colon> character.</blockquote>to:<blockquote>directory names
that could be used in <i>PATH</i> should not include a <colon>
character.</blockquote>
On page 194 line 6983 section 9.5.2 RE and Bracket Expression Grammar,
change:<blockquote>that might be interpreted as
anchors.</blockquote>to:<blockquote>that could be interpreted as
anchors.</blockquote>
On page 253 line 8871 section <fenv.h>, change:<blockquote>when an
application might access the floating-point
environment</blockquote>to:<blockquote>when an application can access the
floating-point environment</blockquote>
On page 282 line 9772 section <limits.h>, change:<blockquote>This
indetermination might depend on the amount of available
memory</blockquote>to:<blockquote>This indetermination could depend on the
amount of available memory</blockquote>
On page 374 line 13122 section <stdint.h>,
change:<blockquote><i>UINT64_C</i>(0x123) might expand to the integer
constant 0x123ULL.</blockquote>to:<blockquote><i>UINT64_C</i>(0x123) can
expand to the integer constant 0x123ULL.</blockquote>
On page 433 line 15052 section <sys/wait.h>, change:<blockquote>A core
image might or might not have been produced.</blockquote>to:<blockquote>It
is possible that a core image was not produced.</blockquote>
On page 458 line 15976 section <unistd.h>, change:<blockquote>the option
shall be supported for compilation and might or might not be supported at
runtime.</blockquote>to:<blockquote>the option shall be supported for
compilation and is possibly supported at runtime.</blockquote>
On page 475 line 16732 section <unistd.h>, change:<blockquote>Option might
or might not be supported.</blockquote>to:<blockquote>Option supported for
compilation and possibly supported at runtime.</blockquote>
On page 496 line 17416 section 2.2.1 POSIX.1 Symbols,
change:<blockquote>control the visibility of symbols that might be included
in a header.</blockquote>to:<blockquote>control the visibility of symbols
included in a header.</blockquote>
On page 524 line 18589 section 2.5.1 Interaction of File Descriptors and
..., change:<blockquote>This might occur during functions such as a
<i>fork</i>() or <i>_exit</i>().</blockquote>to:<blockquote>This could
occur during functions such as <i>fork</i>() or
<i>_exit</i>().</blockquote>
On page 539 line 19232 section 2.9.3 Thread Mutexes,
change:<blockquote>Depending on the mutex type, it might be possible for
another thread to unlock the mutex and recover the state of the
mutex.</blockquote>to:<blockquote>Depending on the mutex type, it is
possible that another thread could unlock the mutex and recover the state
of the mutex.</blockquote>
On page 552 line 19722 section 2.10.11 Socket Receive Queue,
change:<blockquote>the complete record might never be present in the
receive buffer at one time, as a portion might already have been returned
to the application, and another portion might not yet have been received
from the communications provider</blockquote>to:<blockquote>it is possible
that the complete record is never present in the receive buffer at one
time, as a portion could already have been returned to the application, and
another portion could be yet to be received from the communications
provider</blockquote>
On page 563 line 20205 section 2.12 Status Information,
change:<blockquote>A process might not have any status
information</blockquote>to:<blockquote>It is possible that a process does
not have any status information</blockquote>
On page 651 line 22832 section atomic_init(),
change:<blockquote>initializing any additional state that the
implementation might need to carry</blockquote>to:<blockquote>initializing
any additional state that the implementation may need to
carry</blockquote>
On page 657 line 23026 section basename(), and
page 811 line 27766 section dirname(), change:<blockquote>The returned
pointer might be invalidated if</blockquote>to:<blockquote>The returned
pointer may be invalidated if</blockquote>
On page 668 line 23427 section bindtextdomain(), change:<blockquote>A
subsequent call to <i>bind_textdomain_codeset</i>() with a non-empty
<i>domainname</i> argument might invalidate the returned pointer or
overwrite the string content. The returned pointer might also be
invalidated if the calling thread is
terminated.</blockquote>to:<blockquote>A subsequent call to
<i>bind_textdomain_codeset</i>() with a non-empty <i>domainname</i>
argument may invalidate the returned pointer or overwrite the string
content. The returned pointer may also be invalidated if the calling thread
is terminated.</blockquote>
On page 761 line 26261 section cnd_timedwait(), change:<blockquote>the
dynamic binding between condition variable and mutex might be
removed</blockquote>to:<blockquote>the dynamic binding between condition
variable and mutex could be removed</blockquote>
On page 797 line 27312 section ctermid(), and
page 819 line 28021 section dlerror(), and
page 1143 line 39117 section getlogin(), and
page 1829 line 60406 section ptsname(), and
page 2167 line 70814 section strsignal(), and
page 2307 line 75095 section ttyname(), change:<blockquote>The returned
pointer might be invalidated or the string content might be overwritten by
a subsequent call</blockquote>to:<blockquote>The returned pointer may be
invalidated or the string content may be overwritten by a subsequent
call</blockquote>
On page 797 line 27314 section ctermid(), and
page 819 line 28023 section dlerror(), and
page 2167 line 70815 section strsignal(), change:<blockquote>The returned
pointer might also be invalidated if the calling thread is
terminated.</blockquote>to:<blockquote>The returned pointer may also be
invalidated if the calling thread is terminated.</blockquote>
On page 1143 line 39119 section getlogin(), and
page 1829 line 60407 section ptsname(), and
page 2307 line 75096 section ttyname(), change:<blockquote>The returned
pointer and the string content might also be invalidated if the calling
thread is terminated.</blockquote>to:<blockquote>The returned pointer and
the string content may also be invalidated if the calling thread is
terminated.</blockquote>
On page 815 line 27893 section dladdr(), change:<blockquote>all regular
files mapped using <i>mmap</i>() might be
included</blockquote>to:<blockquote>all regular files mapped using
<i>mmap</i>() may be included</blockquote>
On page 815 line 27900 section dladdr(), change:<blockquote>This might no
longer resolve to the file that was mapped</blockquote>to:<blockquote>It is
possible that this no longer resolves to the file that was
mapped</blockquote>
On page 817 line 27956 section dlclose(), change:<blockquote>For instance,
an executable object file that had been loaded with a <i>dlopen</i>()
operation specifying the RTLD_GLOBAL flag might provide a target for
dynamic relocations performed in the processing of other relocatable
objects--in such environments, an application may assume that no
relocation, once made, shall be undone or remade unless the executable
object file containing the relocated object has itself been
removed.</blockquote>to:<blockquote>For instance, an executable object file
that had been loaded with a <i>dlopen</i>() operation specifying the
RTLD_GLOBAL flag could provide a target for dynamic relocations performed
in the processing of other relocatable objects--in such environments, an
application can assume that no relocation, once made, will be undone or
remade unless the executable object file containing the relocated object
has itself been removed.</blockquote>
On page 821 line 28099 section dlopen(), change:<blockquote>Specifying
RTLD_LAZY should improve performance on implementations supporting dynamic
symbol binding since a process might not reference all of the
symbols</blockquote>to:<blockquote>Specifying RTLD_LAZY can improve
performance on implementations supporting dynamic symbol binding since it
is possible that a process does not reference all of the
symbols</blockquote>
On page 822 line 28134 section dlopen(), change:<blockquote>To resolve the
ambiguities such a situation might present</blockquote>to:<blockquote>To
resolve the ambiguities that are possible in such a situation</blockquote>
On page 840 line 28731 section getgrent(), and
page 842 line 28799 section gethostent(), and
page 844 line 28867 section endnetent(), and
page 846 line 28934 section endprotoent(), and
page 848 line 28995 section endpwent(), and
page 851 line 29094 section endservent(), and
page 1128 line 38645 section getgrgid(), and
page 1132 line 38783 section getgrnam(), and
page 1166 line 39840 section getpwnam(), and
page 1170 line 39984 section getpwuid(), and
page 1858 line 61294 section readdir(), change:<blockquote>The returned
pointer, and pointers within the structure, might be invalidated or the
structure or the storage areas might be
overwritten</blockquote>to:<blockquote>The returned pointer, and pointers
within the structure, may be invalidated or the structure or the storage
areas may be overwritten</blockquote>
On page 840 line 28733 section getgrent(), and
page 842 line 28801 section gethostent(), and
page 844 line 28869 section endnetent(), and
page 846 line 28936 section endprotoent(), and
page 848 line 28997 section endpwent(), and
page 851 line 29096 section endservent(), and
page 1128 line 38647 section getgrgid(), and
page 1132 line 38785 section getgrnam(), and
page 1166 line 39842 section getpwnam(), and
page 1170 line 39986 section getpwuid(), and
page 1858 line 61297 section readdir(), change:<blockquote>The returned
pointer, and pointers within the structure, might also be invalidated if
the calling thread is terminated.</blockquote>to:<blockquote>The returned
pointer, and pointers within the structure, may also be invalidated if the
calling thread is terminated.</blockquote>
On page 868 line 29534 section exec, and
page 1582 line 53118 section posix_spawn(), and
page 2503 line 81343 section 2.9.1.5 Standard File Descriptors,
change:<blockquote>consequently the utility or application might not behave
as described in this standard.</blockquote>to:<blockquote>consequently it
is possible that the utility or application does not behave as described in
this standard.</blockquote>
On page 972 line 33059 section fmtmsg(), change:<blockquote>Indicates a
condition that is out of the ordinary, that might be a problem, and should
be watched.</blockquote>to:<blockquote>Indicates a condition that is out of
the ordinary, that could be a problem, and should be watched.</blockquote>
On page 1141 line 39050 section getlocalename_l(), change:<blockquote>the
returned string pointer might be invalidated or the string content might be
overwritten by a subsequent call in the same thread to
<i>getlocalename_l</i>() with LC_GLOBAL_LOCALE; the returned string pointer
might also be invalidated if the calling thread is
terminated.</blockquote>to:<blockquote>the returned string pointer may be
invalidated or the string content may be overwritten by a subsequent call
in the same thread to <i>getlocalename_l</i>() with LC_GLOBAL_LOCALE; the
returned string pointer may also be invalidated if the calling thread is
terminated.</blockquote>
On page 1188 line 40522 section getsubopt(), change:<blockquote>is one of
the possible tokens that might be found in</blockquote>to:<blockquote>is
one of the tokens it is possible to find in</blockquote>
On page 1351 line 45395-45401 section localeconv(), change all uses of
"might" to "may" in the RETURN VALUE section.
On page 1475 line 49504 section msgrcv(), and
page 1478 line 49611 section msgsnd(), change:<blockquote>example of what
this user-defined buffer might look like</blockquote>to:<blockquote>example
of what this user-defined buffer could look like</blockquote>
On page 1510 line 50630-50639 section nl_langinfo(), change all uses of
"might" to "may" in the RETURN VALUE section.
On page 1543 line 51632 section poll(), and
page 1636 line 54581 section pselect(), change:<blockquote>The function
might return data, an end-of-file indication,
or</blockquote>to:<blockquote>The function could return data, an
end-of-file indication, or</blockquote>
On page 1558 line 52228 section posix_devctl(),
change:<blockquote>Corresponding data might be transferred, partially
transferred, or</blockquote>to:<blockquote>Corresponding data may be
transferred, partially transferred, or</blockquote>
On page 1734 line 57636 section pthread_key_create(),
change:<blockquote>even though this might result in an infinite
loop.</blockquote>to:<blockquote>even though this could result in an
infinite loop.</blockquote>
On page 1885 line 62265 section regcomp(), change:<blockquote>any given
parenthesized subexpression of <i>pattern</i> might participate in the
match of several different substrings of <i>string</i>, or it might not
match any substring</blockquote>to:<blockquote>it is possible that any
given parenthesized subexpression of <i>pattern</i> participates in the
match of several different substrings of <i>string</i>, or that it does not
match any substring</blockquote>
On page 1887 line 62333 section regcomp(), change:<blockquote>but it might
not be as detailed under some
implementations.</blockquote>to:<blockquote>but it may be less detailed
under some implementations.</blockquote>
On page 1991 line 65530 section setlocale(), change:<blockquote><CX>The
returned string pointer might be invalidated or</CX> the string content
might be overwritten by a subsequent call to <i>setlocale</i>(). <CX>The
returned pointer might also be invalidated if the calling thread is
terminated.</CX></blockquote>to:<blockquote><CX>The returned string pointer
may be invalidated or</CX> the string content may be overwritten by a
subsequent call to <i>setlocale</i>(). <CX>The returned pointer may also be
invalidated if the calling thread is terminated.</CX></blockquote>
On page 2125 line 69391 section strerror(), change:<blockquote><CX>The
returned string pointer might be invalidated or</CX> the string content
might be overwritten by a subsequent call to <i>strerror</i>(), <CX>or by a
subsequent call to <i>strerror_l</i>() in the same thread. The returned
pointer and the string content might also be invalidated if the calling
thread is terminated.</CX></blockquote>to:<blockquote><CX>The returned
string pointer may be invalidated or</CX> the string content may be
overwritten by a subsequent call to <i>strerror</i>(), <CX>or by a
subsequent call to <i>strerror_l</i>() in the same thread. The returned
pointer and the string content may also be invalidated if the calling
thread is terminated.</CX></blockquote>
On page 2207 line 72088 section system(), change:<blockquote>this might
then cause the program calling <i>system</i>() to
behave</blockquote>to:<blockquote>this can then cause the process calling
<i>system</i>() to behave</blockquote>
On page 2207 line 72097 section system(), change:<blockquote>If this might
cause the application to miss a signal</blockquote>to:<blockquote>If this
could cause the application to miss a signal</blockquote>
On page 2253 line 73523 section thrd_create(), change:<blockquote>A
thread's identifier might be reused for a different
thread</blockquote>to:<blockquote>A thread's identifier can be reused for a
different thread</blockquote>
On page 2258 line 73679 section thrd_exit(), change:<blockquote>calling any
<i>atexit</i>() routines that might
exist.</blockquote>to:<blockquote>calling any <i>atexit</i>() routines that
exist.</blockquote>
On page 2472 line 80094 section 2.2 Quoting, change:<blockquote>and the
following might need to be quoted under certain
circumstances.</blockquote>to:<blockquote>and the following need to be
quoted under certain circumstances.</blockquote>
On page 2489 line 80787 section 2.6.3 Command Substitution,
change:<blockquote>however, they might be treated as field delimiters and
eliminated during field splitting</blockquote>to:<blockquote>however, it is
possible that they will be treated as field delimiters and eliminated
during field splitting</blockquote>
On page 2492 line 80901 section 2.6.5 Field Splitting,
change:<blockquote>The locale might have changed between those
events.</blockquote>to:<blockquote>The locale could have changed between
those events.</blockquote>
On page 2493 line 80953 section 2.6.5 Field Splitting,
change:<blockquote>The ordered list of output fields so produced, which
might be empty,</blockquote>to:<blockquote>The ordered list of output
fields so produced, which can be empty,</blockquote>
On page 2514 line 81807 section 2.10.2 Shell Grammar Rules,
change:<blockquote>Each <b>TOKEN</b> that might either be expanded or have
assignment applied to it</blockquote>to:<blockquote>Each <b>TOKEN</b> that
would either be expanded or have assignment applied to it</blockquote>
On page 2631 line 86291 section awk, change:<blockquote>One convention that
might not be obvious from the formal grammar
is</blockquote>to:<blockquote>One convention that is not be obvious from
the formal grammar is</blockquote>
On page 2676 line 88152 section c17, change:<blockquote>be aware that
binary data placed in shared memory or in files might not be recognized by
applications</blockquote>to:<blockquote>be aware that it is possible for
binary data placed in shared memory or in files not to be recognized by
applications</blockquote>
On page 2776 line 91907 section dd, change:<blockquote>this might entail
multiple reads</blockquote>to:<blockquote>this could entail multiple
reads</blockquote>
On page 2844 line 94452 section ex, change:<blockquote>the first time a
file that already exists (including a file that might not exist but for
which recovery information is available, when the <b>-r</b> option is
specified) replaces</blockquote>to:<blockquote>the first time a file that
already exists (or a file that does not exist but for which recovery
information is available, when the <b>-r</b> option is specified)
replaces</blockquote>
On page 2956 line 98812 section fuser, change:<blockquote>For example,
<i>fuser</i> might first write the information for all file operands to
standard error and then write all of the process IDs to standard
output.</blockquote>to:<blockquote>For example, <i>fuser</i> could first
write the information for all file operands to standard error and then
write all of the process IDs to standard output.</blockquote>
On page 3021 line 101095 section jobs, change:<blockquote>some process IDs
might have been removed from the list but not successfully
reported.</blockquote>to:<blockquote>some process IDs may have been removed
from the list but not successfully reported.</blockquote>
On page 3116 line 104833 section mailx, change:<blockquote>any commands
that might previously have marked the messages to be
deleted</blockquote>to:<blockquote>any commands that could previously have
marked the messages to be deleted</blockquote>
On page 3191 line 107764 section msgfmt, change:<blockquote>shall detect
and diagnose input file abnormalities which might represent translation
errors.</blockquote>to:<blockquote>shall detect and diagnose input file
abnormalities which could represent translation errors.</blockquote>
On page 3194 line 107918 section msgfmt, change:<blockquote>They can be
added, as might "#." prefixed additional
comments</blockquote>to:<blockquote>They can be added, as can "#." prefixed
additional comments</blockquote>
On page 3195 line 107922 section msgfmt, change:<blockquote>This flag
indicates that the <b>msgstr</b> string might not be a correct
translation</blockquote>to:<blockquote>This flag indicates that the
<b>msgstr</b> string is possibly not a correct translation</blockquote>
On page 3274 line 110990 section pax, change:<blockquote>meets any
selection criteria that might be imposed on the format-reading utility by
the user</blockquote>to:<blockquote>meets any selection criteria imposed on
the format-reading utility by the user</blockquote>
On page 3619 line 123920 section yacc, change:<blockquote>actions within
rules might introduce conflicts that would not otherwise
exist.</blockquote>to:<blockquote>actions within rules could introduce
conflicts that would not otherwise exist.</blockquote>
On page 3622 line 124052 section yacc, change:<blockquote>Some grammar
rules might not have both precedence and
associativity.</blockquote>to:<blockquote>It is possible for some grammar
rules not to have both precedence and associativity.</blockquote>
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2024-11-19 15:10 geoffclare New Issue
2024-11-19 15:10 geoffclare Name => Geoff Clare
2024-11-19 15:10 geoffclare Organization => The Open Group
2024-11-19 15:10 geoffclare Section => (many)
2024-11-19 15:10 geoffclare Page Number => (many)
2024-11-19 15:10 geoffclare Line Number => (many)
2024-11-19 15:10 geoffclare Interp Status => ---
======================================================================
