@ page 997 line 31631 section pthread_attr_getstacksize() objection
Problem:
The thread stack size functions pthread_attr_getstacksize() and
pthread_attr_setstacksize() are listed under the thread stack
address option (code TSA), but should be listed under the thread
stack size option (code TSS)
Action:
Change the code TSA into the correct code TSS
------------
@ page 953 line 30466 section posix_trace_open() objection
Problem:
posix_trace_open() and posix_trace_rewind() are wrongly listed
under the TCT option code (thread cpu-time). They should be under
the TRC option code (POSIX Tracing).
These functions are described under posix_trace_close() and the
option in that section is correct.
Action:
Change the TCT option code into the correct TRC code.
-------------
@ page 923 line 29616 section posix_trace_attr_setlogfullpolicy()
objection
Problem:
The posix_trace_attr_setlogfullpolicy() is not listed under the Trace
Log option (code TRL), but under trace inheritance (code TRI).
This function is described under posix_trace_attr_getinherited()
and the option in that section is correct.
Action:
Add the TRL and TRC codes to the
posix_trace_attr_setlogfullpolicy() function synopsis.
-------------
@ page 926 line 29648 section posix_trace_setstreamfullpolicy()
objection
Problem:
The posix_trace_setstreamfullpolicy() function is incorrectly named
as posix_trace_setlogfullpolicy() in the synopsis.
This function is described under posix_trace_attr_getinherited()
and the name in that section is correct.
Action:
Change the incorrect name posix_trace_setlogfullpolicy() into
posix_trace_setstreamfullpolicy()
-------------
@ page 944 line 30224 section posix_trace_flush() objection
Problem:
The posix_trace_flush() function is listed under the TRC (Tracing)
option
code only, but should also be under the TRL code (Trace log
option).
This function is described under posix_trace_create() and the
option codes there are correct.
Action:
Add the missing TRL option code.
-------------
@ page 771 line 25175 section mmap() objection
Problem:
The mmap() function is only under the memory-mapped files (MF code) or
the shared memory objects (SHM code) options, but should be also under
the typed memory objects option (TYM code). It was under any of the
three options in POSIX.1j.
Action:
Replace the codes MF|SHM in the synopsis section with the correct
codes MF|SHM|TYM.
-------------
@ page 817 line 26583 section munmap() objection
Problem:
The munmap() function is only under the memory-mapped files (MF code)
or the shared memory objects (SHM code) options, but should be also
under the typed memory objects option (TYM code). It was under any of
the three options in POSIX.1j.
Action:
Replace the codes MF|SHM in the synopsis section with the correct
codes MF|SHM|TYM.
-------------
@ page 1228 line 38226 section sched_get_priority_max() objection
Problem:
The sched_get_priority_max() and sched_get_priority_min() functions
are required for the application to determine the range of priorities
that are valid for a given scheduling policy, such as SCHED_FIFO. If
these functions are not present, it is not possible for an application
to determine which are the valid priorities (for example, an
implementation might legally use a range between 337-369 for some
obscure reason).
The problem is that these functions are not required under the thread
priority scheduling option (TPS code); they are only required under
the process priority scheduling option. Therefore, it is not possible
to write a strictly conforming application that sets its priority for
an implementation supporting thread priority scheduling but not
process priority scheduling (as mandated for example in the POSIX.13
small realtime profiles).
This problem was also present in POSIX.1-1996, but was not discovered
until the first implementations of the POSIX.13 minimal realtime
system profile.
Action:
Change the PS code in the synopsis of these two functions into
PS|TPS (process priority scheduling or thread priority scheduling)
-------------
@ page 1231 line 38343 section sched_rr_get_interval() objection
Problem:
The sched_rr_get_interval() function is required for the application
to determine the interval for the round robin scheduler. If this
function is not present, it is not possible for an application to
determine which is this interval.
The problem is that this function is not required under the thread
priority scheduling option (TPS code); it is only required under the
process priority scheduling option. Therefore, it is not possible to
write a strictly conforming application that uses the round robin
interval, for an implementation supporting thread priority scheduling
but not process priority scheduling (as mandated for example in the
POSIX.13 small realtime profiles).
This problem was also present in POSIX.1-1996, but was not discovered
until the first implementations of the POSIX.13 minimal realtime
system profile.
Action:
Change the PS code in the synopsis of this function into PS|TPS
(process priority scheduling or thread priority scheduling)
|