@ page 845 line 26507,26509 section posix_spawn() editorial [prindle.xsh-1]
Problem:
posix_spawnattr_getdefault() should be posix_spawnattr_getsigdefault().
posix_spawnattr_setdefault() should be posix_spawnattr_setsigdefault().
This editorial error was discovered during final pre-publication editing of
1003.1d. Note that the correct name is used throughout .1d, and only appears
misspelled this way in the synopsis section and the header section of the
example. It is spelled correctly elsewhere. During the merge into Austin D3
the misspelled version seems to have propogated everywhere!
This problem also applies to:
page 854 line 26782,26784 section posix_spawnattr_destroy()
page 855 line 26791,26796,26798,26805,26807,26810,26813,26818 section
posix_spawnattr_getdefault()
page 858 line 26881,26883 section posix_spawnattr_getflags()
page 859 line 26926,26928 section posix_spawnattr_getgroup()
page 861 line 26975,26977 section posix_spawnattr_getschedparam()
page 863 line 27023,27025 section posix_spawnattr_getschedpolicy()
page 865 line 27071,27072 section posix_spawnattr_getsigmask()
page 868 line 27088,27093,27097 section posix_spawnattr_setdefault()
Action:
Fix the spelling of these functions everywhere (I've attempted to locate all
the occurrences, but Acrobat's find function is not all that reliable).
-------------------------------------------------------------------------------
@ page 756 line 23805,23808-23811 section mq_receive() objection [prindle.xsh-2]
Problem:
Yes indeed, return type should be ssize_t. This opinion is confirmed by Michael
Gonzalez, technical editor for .1d.
This problem also applies to:
page 763 line 24027 section mq_timed_receive()
Action:
Delete this note and...
Change the first "int" on lines 23805 and 24027 to "ssize_t".
If deemed necessary, file a POSIX interpretation request to place this change
into the scope of the .1 revision (SSWG-RT will immediately recommend the fix
as part of the interpretation, because as it stands the .1d standard is
inconsistent with .1 mq_receive()).
-------------------------------------------------------------------------------
@ page 833 line 23038-26044 section posix_madvise() objection [prindle.xsh-3]
Problem:
Yes indeed, the correct header should be <sys/mman.h>. This opinion is
confirmed by Michael Gonzalez, technical editor for .1d.
Action:
Delete this note and accept objection [prindle.xbd-6] (moves this function's
prototype from <fcntl.h> to <sys/mman.h>).
If deemed necessary, file a POSIX interpretation request to place this change
into the scope of the .1 revision (SSWG-RT will immediately recommend the fix
as part of the interpretation, because as it stands the .1d standard is
internally inconsistent).
-------------------------------------------------------------------------------
@ page 195 line 6134 section clock_getcpuclockid() editorial [prindle.xsh-4]
Problem:
Missing return type.
Action:
Add "int" before the function name.
-------------------------------------------------------------------------------
@ page 197 line 6226,6235 section clock_getres() editorial [prindle.xsh-5]
Problem:
There are several clock_*() functions, distinct from the clock() function.
Action:
Change "clock()" on these two lines to "clock_*()".
-------------------------------------------------------------------------------
@ page 258 line 8200 section endhostent() objection [prindle.xsh-6]
Problem:
These functions are not thread safe in two different ways (there has been
recent email discussion regarding flavors of thread safety). gethostent() is
not safe because it returns a pointer to a potentially static structure.
They all are not thread safe because of the positional state retained among
them - i.e. separate threads expecting to search independently through or
rewind the database will interfere with each other. You've made a decision
in the other get*ent()/set*ent()/end*ent() type functions to consider the
entire set non-thread-safe.
Action:
Add (as in endgrent()) the following paragraph:
These functions need not be reentrant. A function that is not required to be
reentrant is not required to be thread-safe.
-------------------------------------------------------------------------------
@ page 260 line 8253 section endnetent() objection [prindle.xsh-7]
Problem:
These functions are not thread safe in two different ways (there has been
recent email discussion regarding flavors of thread safety). getnet*() are
not safe because they returns pointers to potentially static structures.
They all are not thread safe because of the positional state retained among
them - i.e. separate threads expecting to search independently through or
rewind the database will interfere with each other. You've made a decision
in the other get*ent()/set*ent()/end*ent() type functions to consider the
entire set non-thread-safe.
Action:
Add (as in endgrent()) the following paragraph:
These functions need not be reentrant. A function that is not required to be
reentrant is not required to be thread-safe.
-------------------------------------------------------------------------------
@ page 262 line 8305 section endprotoent() objection [prindle.xsh-8]
Problem:
These functions are not thread safe in two different ways (there has been
recent email discussion regarding flavors of thread safety). getproto*() are
not safe because they returns pointers to potentially static structures.
They all are not thread safe because of the positional state retained among
them - i.e. separate threads expecting to search independently through or
rewind the database will interfere with each other. You've made a decision
in the other get*ent()/set*ent()/end*ent() type functions to consider the
entire set non-thread-safe.
Action:
Add (as in endgrent()) the following paragraph:
These functions need not be reentrant. A function that is not required to be
reentrant is not required to be thread-safe.
-------------------------------------------------------------------------------
@ page 266 line 8422 section endservent() objection [prindle.xsh-9]
Problem:
These functions are not thread safe in two different ways (there has been
recent email discussion regarding flavors of thread safety). getserv*() are
not safe because they returns pointers to potentially static structures.
They all are not thread safe because of the positional state retained among
them - i.e. separate threads expecting to search independently through or
rewind the database will interfere with each other. You've made a decision
in the other get*ent()/set*ent()/end*ent() type functions to consider the
entire set non-thread-safe.
Action:
Add (as in endgrent()) the following paragraph:
These functions need not be reentrant. A function that is not required to be
reentrant is not required to be thread-safe.
-------------------------------------------------------------------------------
@ page 573 line 18137 section if_freenameindex() comment [prindle.xsh-10]
Problem:
This line talks about the "if_nameindex" argument. The argument is really named
"ptr". "if_nameindex" is the name of a function and also a structure, but
not an agrument.
Action:
Change "if_nameindex argument" to "ptr argument".
-------------------------------------------------------------------------------
@ page 586 line 18415 section inet_ntop() comment [prindle.xsh-11]
Problem:
These functions are marked as part of the IP6 option. The equivalent IPv4
functions (inet_addr(), inet_ntoa()) are marked LEGACY and should not be used
in new applications. This creates a problem for applications targeted for
implementations not supporting the IP6 option. In a pinch, getipnodebyname()
can substitute for inet_addr(), but getipnodebyaddr() would not appear to
provide the functionality of inet_ntoa(). The legacy functions have not info
in APPLICATION USAGE suggesting other alternatives.
Action:
Make these functions mandatory, and mark IPv6 specific functionality as part
of the IP6 option, but have IPv4 functionality supported by all
implementations (i.e. leave unshaded).
-------------------------------------------------------------------------------
@ page 737 line 23155 section mmap() objection [prindle.xsh-12]
Problem:
This line contradicts what is above. It was never modified to allow typed
memory objects.
Action:
Change the shaded "and shared memory objects" to ", shared memory objects, and
typed memory objects", and change margin code to SHM|TYM.
-------------------------------------------------------------------------------
@ page 829 line 25962 section posix_fadvise() editorial [prindle.xsh-13]
Problem:
The "if the Advisory Information option is supported." is redundant given
that this page is under the ADV option already, as are the symbols in <fcntl.h>.
Action:
Delete the phrase "if...supported"
-------------------------------------------------------------------------------
@ page 833 line 26070-26071 section posix_fadvise() editorial [prindle.xsh-14]
Problem:
The "if the Advisory Information ... supported." is redundant given
that this page is under the ADV and MF|SHM options already, as should be the
symbols in <fcntl.h> (see [prindle.xbd-7]).
Action:
Delete the phrase "if...supported" (through second "supported")
-------------------------------------------------------------------------------
@ page 385 line 12360 section free() objection [prindle.xsh-15]
Problem:
This line is inconsistent with page 837, line 26157-26158, section
posix_memalign(). Specifically, it should allow posix_memalign() in the set of
functions that may have returned the pointer to storage to be freed.
Action:
Add posix_memalign() to the 3 functions listed here.
This is not a POSIX.1 interpretation issue, as POSIX.1 does not define the
semantics of free() other than in .1d (posix_memalign()).
-------------------------------------------------------------------------------
@ page 839 line 26254,26259 section posix_spawn() editorial [prindle.xsh-16]
Problem:
No shading for optional text.
Action:
Delete (in both lines) "_POSIX_PRIORITY_SCHEDULING is defined, and". Shade
both these paragraphs, and use margin code PS.
-------------------------------------------------------------------------------
@ page 840 line 26295 section posix_spawn() editorial [prindle.xsh-17]
Problem:
No shading for optional text.
Action:
Delete "If the threads option is supported, then". Shade this paragraph, and
use margin code THR.
-------------------------------------------------------------------------------
@ page 841 line 26317,26323 section posix_spawn() editorial [prindle.xsh-18]
Problem:
No shading for optional text.
Action:
Delete (in both lines) "_POSIX_PRIORITY_SCHEDULING is defined, and". Shade
both these paragraphs, and use margin code PS.
-------------------------------------------------------------------------------
@ page 841 line 26338 section posix_spawn() editorial [prindle.xsh-19]
Problem:
Note to reviewers here.
Action:
Yes, the example is of an implementation, not usage. But let's not lose it!
N.B.: There is actually a bug in the example related to [prindle.xsh-1] - that
is, posix_spawnattr_setsigdefault() is misspelled posix_spawnattr_setdefault()
in the prototype - C doesn't catch this error because prototypes are not
enforced. Michael Gonzalez will fix in .1d, we need to fix in our copy of the
example.
-------------------------------------------------------------------------------
@ page 843 line 26420 section posix_spawn() editorial [prindle.xsh-20]
Problem:
The Ada procedure name in the header should be italicized to match this doc's
convention for naming Ada procedures.
Action:
Italicize POSIX_Process_Primitives.Start_Process.
-------------------------------------------------------------------------------
@ page 846 line 26517-26518 section posix_spawn_file_actions_addclose()
objection [prindle.xsh-21]
Problem:
I've said it once, and I'll say it again, there is no fundamental reason to
separate posix_spawn_file_actions_adddup2() from these two. But if you insist,
let's at least get the description right.
Action:
Change "close and open spawn file actions object" to "add close or open to
spawn file actions object". On page 849, line 26625, change "add to spawn file
actions object" to "add dup2 to spawn file actions object. On page 850, line
26667, change "open spawn file actions object" to "add open to spawn file
actions object".
Better yet, combine these two pages and use the unified description on this
and the other reference pages.
-------------------------------------------------------------------------------
@ page 851 line 26694 section posix_spawn_file_actions_destroy() editorial
[prindle.xsh-22]
Problem:
An important semantic regarding posix_spawn_file_actions_init() seems to have
been misplaced here regarding initializing an already initialized object. The
missing paragraph is accidentally on line 26754 of page 853.
Action:
Add paragraph (from .1d):
The effect of initializing an already initialized spawn file actions object
is undefined.
Delete this paragraph from line 26754 of page 853.
-------------------------------------------------------------------------------
@ page 853 line 26754 section posix_spawnattr_destroy() comment [prindle.xsh-23]
Problem:
Bob Barned has already identified a similar inconsistency in POSIX.1c, that is
it is not clear if it is permissible to reinitialize an already initialized
thread attribute object. It would seem clear from the presence of the destroy
operation that such a thing should result in undefined behavior, but it should
be clearly stated here, for posix_spawnattr_init() as it was for
posix_spawn_file_actions_init().
Action:
Add in place of this erroneous line:
"The effect of initializing an already initialized spawn attributes object is
undefined."
If deemed necessary, file a POSIX interpretation request to place this change
into the scope of the .1 revision.
-------------------------------------------------------------------------------
@ page 886 line 27488 section pthread_attr_destroy() comment [prindle.xsh-24]
Problem:
Bob Barned identified that the treatment of this kind of attribute object is
inconsistent with other such attribute objects in .1c. Namely, it is unclear
what the effect of initializing an already initialized thread attributes object
is.
Action:
Add:
"The effect of initializing an already initialized thread attributes object is
undefined."
If deemed necessary, file a POSIX interpretation request to place this change
into the scope of the .1 revision.
-------------------------------------------------------------------------------
@ page 857 line 26851-26853 section posix_spawnattr_getflags() editorial
[prindle.xsh-25]
Problem:
No shading for optional text.
Action:
Replace "and POSIX_SPAWN_SETSIGMASK. In addition, if the Process Scheduling
option is supported, the flags" with "POSIX_SPAWN_SETSIGMASK,
POSIX_SPAWN_SETSCHEDPARAM, and POSIX_SPAWN_SETSCHEDULER". Shade the last two
flags, and use margin code PS.
-------------------------------------------------------------------------------
@ page 861 line 26938,26939 section posix_spawnattr_getschedparam() editorial
[prindle.xsh-26]
Problem:
POSIX.1d specified these two includes in the opposite order.
This problem also applies to:
page 863 line 26987,26988 section posix_spawnattr_getschedpolicy()
Action:
Reverse the order of these includes for consistency with the base standard.
-------------------------------------------------------------------------------
@ page 912 line 28030-28034 section pthread_barrier_destroy() comment
[prindle.xsh-27]
Problem:
I don't understand this Note to Reviewers at all.
This problem also applies to:
page 1043 line 31691-31696 section pthread_spin_destroy()
Action:
Explain what all this means. I can't see any difference between how this is
handled here (may fail) from any other init/destroy pair.
-------------------------------------------------------------------------------
@ page 1014 line 30996 section pthread_rwlock_destroy() comment [prindle.xsh-28]
Problem:
It isn't clear when a process would not have such privilege. This is not in
POSIX .1j. If it is included here, it ought to be marked MAN or something like
that to indicate that it is an extension to POSIX, and the description should
indicate when such a failure might occur.
Action:
Shade this line MAN. Modify description to indicate what might fail without
sufficient privilege.
-------------------------------------------------------------------------------
@ page 1017 line 31043 section pthread_rwlock_rdlock() comment [prindle.xsh-29]
Problem:
It is not clear why these two POSIX options should be merged into one.
Action:
I'll support this if it can be proven that no RT profile that supports threads
couldn't do without this (coordinate with Michael Gonzalez and SSWG-RT proposal
for 1003.13b at July POSIX meeting).
-------------------------------------------------------------------------------
@ page 1019 line 31149 section pthread_rwlock_timedrdlock() comment
[prindle.xsh-30]
Problem:
Elsewhere, wording regarding the potential for deadlock was changed to indicate
that deadlock may either occur or be detected, but not here.
This problem also applies to:
page 1021 line 31210 section pthread_rwlock_timedwrlock()
Action:
Change the first sentence (31149) to:
Results are undefined if the calling thread holds a write lock on rwlock at
the time the call is made.
Change the second sentence (31210) to:
Results are undefined if the calling thread holds the read-write lock (whether
a read or write lock) at the time the call is made.
-------------------------------------------------------------------------------
@ page 1096 line 33217-33240 section recv() comment [prindle.xsh-31]
Problem:
recv() is essentially a read() with socket specific flags and some socket
specific errors not returned by read(). Some of the errors here (and not
in read()) would seem to be in common with read, especially when either is
used to read from a connection oriented socket:
EFAULT
ENOMEM
ENOSR
Also note that EIO is may fail here, and shall fail in read().
In fact, APP USAGE implies identity with read() when no flags are specified,
yet read() has a smaller error set when reading from sockets.
This problem also applies to:
page 1175-1176 line 35865-35892 section send()
Action:
Consider harmonizing the set of errors between recv() and read() where the
errors have nothing to do with the flags. I know this is vague, but don't
fully understand the rationale regarding why these errors were not applied
to read() by XNS when reading from a socket.
Same applies to send() and write().
-------------------------------------------------------------------------------
@ page 1100 line 33387-33388 section recvmsg() editorial [prindle.xsh-32]
Problem:
Several references to rcvfrom() that appear they should be to rcvmsg().
Action:
Replace any rcvfrom() function references in this section with rcvmsg() (except
in SEE ALSO of course).
-------------------------------------------------------------------------------
@ page 1144 line 31778-31784 section select() objection [prindle.xsh-33]
Problem:
POSIX.1g, approved but in the process of being withdrawn, indicated that the
ballot group supported two differences from what is given here:
1. Require caller to include <sys/select.h>
It is really wierd for <sys/time.h> to have to include <sys/select.h>
because the relationship is in the opposite direction (select uses
timeval, nothing in <sys/time.h> needs to use select). I know
implementations are doing this, but that doesn't make it any less wierd.
2. Add pselect() and deprecate select()
select() allows control to return to caller only at 1ms intervals at
best when no FD is ready. Every other timed function uses timespec
instead of timeval, giving down to 1 nanosecond resolution which is
better for RT systems. pselect() adds this capability.
Action:
Align this page with 1003.1g in these respects.
-------------------------------------------------------------------------------
@ page 1375 line 41788 section sysconf() comment [prindle.xsh-34]
Problem:
Some introductory text here is missing. The symbols from 41788 onward are not
introduced by amendment 1003.1j, but more likely by by 1003.2b (?).
Action:
Put these symbols under the appropriate introductory paragraph.
-------------------------------------------------------------------------------
@ page 1435 line 43595 section tsearch() editorial [prindle.xsh-35]
Problem:
This page seems to defy the convention that a page that contains multiple
interfaces should appear in the place where the alphabetically first interface
name would appear, and all other functions backward reference to that place.
Here tsearch() is third.
Action:
Move this page to the position of tdelete(), and make tfind(), tsearch(), and
twalk() back reference pages.
-------------------------------------------------------------------------------
@ page 1412 line 42854 section timer_create() objection [prindle.xsh-36]
Problem:
The wording "If...supported, all implementations shall..." is nonsense.
The word "all" causes the problem.
Action:
Delete the word "all".
-------------------------------------------------------------------------------
@ page All line All section All objection [prindle.xsh-37]
Problem:
Throughout this draft, the qualifying phrase (for assertions which are not true
unless an option is supported) takes on two distinctly different and
inconsistent forms:
If <OPTION_SYMBOL> is defined...
and
If the <Option_Name> option is supported...
Specific instances of this problem occurs on page 1412, at lines 42854,
42858, and 42860, but it occurs numerous other places as well.
The document should be consistent in the way in which this is handled. In
particular, since the whole issue of how options relate to the definition and/or
value of compile-time symbols, and how they relate to the values returned by
sysconf() is rather ill-defined at this time across the entire set of options
(see [prindle.xbd-1]), the more suitable form is the second (using the option
name and the word supported) because it is independent from how support for the
option is indicated; this was determined to be the preferrable solution many
years ago by the SSWG-RT working group.
Action:
Change all occurrences of "If <OPTION_SYMBOL> is defined" to "If the
<Option_Name> option is supported".
-------------------------------------------------------------------------------
@ page 1434 line 53571 section truncate() objection [prindle.xsh-38]
Problem:
The error (necessitated by P1003.1a):
[ELOOP] More than {SYMLOOP_MAX} symbolic links were encountered during
resolution of the path argument.
is missing for the regular file named by path.
This is potentially a global problem. Since P1003.1a amended 1003.1 and not
XSH, it would not have shown this error being added to XSI or C unique functions
not in POSIX.1.
Action:
Add this error here, and in all XSI and C functions which take a pathname or
filename argument that is required to be in the filesystem namespace. Note that
functions such as mq_open(), sem_open(), shm_open() which do not require the
object named be in the filesystem namespace (but allow it), do not specify
ELOOP errors, either the mandatory one or the optional one; so if any XSI
functions fall in this category, do not add this in that case.
Food for thought: if a named semaphore, for example, IS implemented as a
special file in the filesystem, are symbolic links to it valid? Should the
standard be addressing the potential symlink errors in the context of these
special namespaces that may in fact be the filesystem namespace?
-------------------------------------------------------------------------------
@ page 1155 line 35187 section sem_post() editorial [prindle.xsh-39]
Problem:
The work "schedule" is wrong.
Action:
Change "schedule" to either "scheduler" (consistent with paragraph above) or
"scheduling policy" (more consistent with rest of spec).
-------------------------------------------------------------------------------
@ page 964 line 29480 section pthread_getschedparam() objection [prindle.xsh-40]
Problem:
During the merge of 1003.1d the word "of" in this line was used to replace the
word "for" in 1003.1d. While this sentence is confusing at best, changing this
to "of" makes it worse.
Action:
Restore the phrase as it was in 1003.1d: "with the exception for the
pthread_setschedparam() function that...".
-------------------------------------------------------------------------------
@ page 1413 line 42876-42878 section timer_create() editorial [prindle.xsh-41]
Problem:
This error should be shaded and margin marked with CPT|TCT.
Action:
Shade and mark CPT|TCT.
-------------------------------------------------------------------------------
|