Use of the information contained in this unapproved document is at your own risk
.Last update: 10 April,2001
1003.1-96 #123
_____________________________________________________________________________
Interpretation Number: XXXX
Topic: 1003.1q errors
Relevant Sections: Section 21.3.2.4
PASC Interpretation Request: (Defect Report)
----------------------------
Date: 2001 23 Jan
------------------------------------------------------------------------
7 Defect Report concerning (number and title of International Standard
or DIS final text, if applicable):
Additional Realtime Extensions: IEEE Std 1003.1q-2000
------------------------------------------------------------------------
8 Qualifier (e.g. error, omission, clarification required):
1
Error=1 , Omission=2, Clarification=3
------------------------------------------------------------------------
9 References in document (e.g. page, clause, figure, and/or table
numbers):
Draft 8 dated March 2000, Page 34, Section 21.3.2.4, Lines 470-472
Draft 8 dated April 2000, Page 35, Section 21.3.2.4, Lines 477-479
------------------------------------------------------------------------
10 Nature of defect (complete, concise explanation of the perceived
problem):
Note that the ENOMEM error for posix_trace_attr_init() is optional;
that is, it need only be returned if the insufficient memory condition
is detected. The corresponding ENOMEM error for pthread_attr_init() is
mandatory; that is, it must be returned if it occurs, so it must be
detected if it occurs.
There are far too many optional error values specified throughout the
standard, as compared to similar functions in other standards. I suspect
the following errors, currently optional, should be mandatory:
Draft 8 dated March 2000 Draft 8 dated April 2000
------------------------ ------------------------
P34, L472 P35, L479
P36, L542 P37, L549
P39, L671 P40, L678
P42, L776 P43, L783
P48, L987 P49, L995
P50, L1070 P51, L1078
P50, L1073 P51, L1081
P50, L1077 P51, L1085
P51, L1115 P52, L1123
P53, L1182 P54, L1190
P54, L1235 P56, L1243
P54, L1237 P56, L1245
P56, L1274 P57, L1282
P56, L1276 P57, L1284
P58, L1347 P59, L1355
P59, L1397 P60, L1405
P59, L1399 P60, L1407
P61, L1450 P62, L1458
P63, L1556 P65, L1561
P63, L1559 P65, L1564
P63, L1562 P65, L1567
P64, L1566 P65, L1571
P64, L1568 P65, L1573
------------------------------------------------------------------------
11 Solution proposed by the submitter (optional):
Change the wording above the listed errors from "If the following
condition(s) is(are) detected" to "If the following condition(s)
occur(s)". (but review the list above for completeness and/or
correctness)
------------------------------------------------------------------------
Interpretation response
------------------------
The standard is clear - an implementation is not required to detect or return
and error indication for any of the errors specified above.
However, the working group intended that implementations be required to detect
many of these errors and return an error indication. The "if detected"
terminology in many of these error descriptions was inadvertently carried
forward from, for example, line 480 on page 35, or line 1411 on page 60,
where it is legitimate. From the list above, however, several are correct as
"if detected" based on precedent - that is, those which return EINVAL when
an argument is invalid but no specific explanation of what constitutes
invalid is specified (L549, 678, 783, 1190). See pthread_attr_setscope(),
pthread_attr_setpolicy(), pthread_attr_setschedparam() for precedent regarding
this incompletely specified type of error.
This is a defect in the standard. Forward to sponsor with a
recommendation to adopt the solution proposed by the submitter except do
not change the "if detected" for the errors listed on lines 549, 678, 783, and
1190, since these do not specify testable criteria for invalidity of the
argument(s).
Rationale
-------------
Francois Riche's response follows:
It would make sense to make these changes for consistency with pthread
library, for example pthread_attr_init() function.
Notes to the Project Editor (not part of this interpretation):
---------------------------------------------------------------
AGR D5
@ page 1434 line 29983 section posix_trace_clear() objection
The same problem and action also applies to:
page 1409 line 29504 [is for some reason already fixed in D5]
page 1445 line 30363
page 1445 line 30365
page 1445 line 30370
page 1450 line 30498
page 1454 line 30616
page 1464 line 30810
page 1443 line 30282
page 1436 line 30036
page 1452 line 30561
page 1458 line 30724
page 1458 line 30726
page 1458 line 30728
page 1458 line 30731
Problem:
There are far too many optional error values specified throughout the trace
functions, as compared to other similar functions in the standards. The lines
indicated reflect currently optionally detected error conditions that should
be mandatory for implementations.
Action:
Change "may" on these lines to "shall".
Forwarded to Interpretations Group: 25 January 2001
Proposed resolution: 21 March 2001
Finalized: April 5 2001