Re: linuxthreads question

[Roland McGrath <roland@frob.com>]

> Well, this can be interpreted in the one or other way.  

Your interpretation is too narrow and fails to take the context of the rest
of the standard into account.

Firstly, it is absolutely clear that POSIX allows any call to return
additional error codes not specified for that call in the standard, for
cases that are not specifically covered by the standard's language.  I cite
1003.1-1996 2.4 ll 790-792 (p 33): "Implementations may support additional
errors not listed in this clause, but shall not generate a different error
number from one required by [1003.1] for an error condition described in
[1003.1]."

I contend that this is such a case.  In support of this I cite 1003.1-1996
2.4 ll 922-925 (p 36), which defines ENOTSUP to mean, "The
implementation does not support this feature of the standard."

It seems clear to me that the error that ENOTSUP is intended to indicate is
use of a feature that does not exist at all in the system (such as an
unsupported schedulin policy type).  A permission failure because the
process is not authorized to use a supported policy is a different
condition, and EPERM is a good match for that condition.  Since it is a
distinct condition that is not addressed specifically for this function in
the standard, the standard allows us to return an error code that is not
listed for the function.