Use of the information contained in this unapproved document is at your own risk
.Last update: 10 April,2001
1003.1-96 #88
_____________________________________________________________________________
Interpretation Number: XXXX
Topic: PTHREAD_KEYS_MAX
Relevant Sections: 2.8.5, 4.8.1.2
PASC Interpretation Request: (Defect Report)
----------------------------
Date: Sun Apr 19 09:12:15 BST 1998
------------------------------------------------------------------------
7 Defect Report concerning (number and title of International Standard
or DIS final text, if applicable):
IEEE Std 1003.1-1996 (incorporates 1003.1-1990, 1003.1b-1993, 1003.1c-1995, 1003.1i-1995) (ISO 9945-1:1996)
------------------------------------------------------------------------
8 Qualifier (e.g. error, omission, clarification required):
3
Error=1 , Omission=2, Clarification=3
------------------------------------------------------------------------
9 References in document (e.g. page, clause, figure, and/or table
numbers):
p 50, clause 2.8.5, table 2-5, line 1492; p111, clause 4.8.1.2
------------------------------------------------------------------------
10 Nature of defect (complete, concise explanation of the perceived
problem):
Q1. How accurate does the value returned by sysconf(_SC_THREAD_KEYS_MAX)
have to be?
Q2.Should an application be able to utilise the exact number returned ?
Q3.Is an implementation allowed to use some keys in its system
libraries?
Q4.Is an implementation which claimed to provide a
maximum of 256 (for example) thread specific data keys but actually
could provide only 3 (to pick an extreme case) keys to an application
(the rest being used by system libraries, etc) conforming?
------------------------------------------------------------------------
11 Solution proposed by the submitter (optional):
For all four questions:
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on this.
This is being referred to the sponsor.
------------------------------------------------------------------------
Interpretation:
---------------
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on
this. This is being referred to the sponsor.
Rationale
-------------
Forwarded to Interpretations group: 19 Apr 1998
Proposed interpretation: 17 Jul 1998
Finalised: February 17 1999