Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretation for IEEE Std 1003.1™-1990 IEEE Standard for Information Technology--Portable Operating System Interfaces (POSIX®)

Copyright © 2001 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #123
Topic:
1003.1q errors Relevant Sections: Section 21.3.2.4 PASC

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

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 for Interpretation
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