@ page 1272-1273 line 39878-39907 section sem_open objection [gwc semaphore
names]
Problem:
Defect code : 1. Error
The sem_open() page has some problems regarding how semaphore names
relate to the rules for pathnames.
The main problem concerns the values of NAME_MAX and PATH_MAX for
semaphore names. The standard states "The name argument conforms to
the construction rules for a pathname", and these rules include (via
the definitions of "pathname" and "filename") length requirements
related to NAME_MAX and PATH_MAX. This is also apparent from the
description of the ENAMETOOLONG error on the sem_open() page:
"[ENAMETOOLONG]
The length of the name argument exceeds {PATH_MAX} or a
pathname component is longer than {NAME_MAX}."
If NAME_MAX or PATH_MAX is not defined as a constant in <limits.h>,
how is an application supposed to determine the value that applies
to semaphore names? The standard says on the <limits.h> page that
in this case the values can be obtained from pathconf(), but
semaphore names do not have to appear in the file system, so it is
unclear how pathconf() can be used (portably) to do this.
Even if semaphore names do appear in the file system, there is
nothing to suggest that the place they appear is the same one that
would result from using the semaphore name as a normal pathname.
(I imagine that all implementations that do make semaphores visible
in the file system would put them in a different location, otherwise
there would be an unacceptable risk of name clashes with normal files
in the root directory.)
This means that the value obtained from
pathconf(dirname(semaphore_name), _PC_NAME_MAX) might not be the
correct value of NAME_MAX. E.g. if semaphores appear somewhere on
the /var file system and /var has a different NAME_MAX value from the
root file system, then the correct NAME_MAX value could be obtained
using pathconf("/var", _PC_NAME_MAX) but there is no portable way for
an application to know that it needs to use "/var" as the directory
name to pass to pathconf() rather than "/". It also means that the
value of PATH_MAX, whether obtained from pathconf() or from <limits.h>,
may be too large. E.g. if the implementation prefixes "/var/semaphores"
to supplied semaphore names and then just uses the resulting string as
a pathname then an ENAMETOOLONG error will occur for semaphore names
longer than PATH_MAX minus strlen("/var/semaphores"). Requiring
implementations to go through hoops so that semaphore names up to
PATH_MAX bytes in length are usable does not seem reasonable.
(There is also a knock-on effect here which creates a problem for the
POSIX.13 PSE51 profile of POSIX.1-2001, since PSE51 mandates sem_open()
but does not mandate pathconf().)
I considered various solutions to the pathconf() issue, initially based
on the idea that the "real" pathname rules should apply if semaphore
names appear in the file system, but other rules would apply if they
do not. I eventually concluded that there is no advantage for
applications in these kind of solutions. Portable applications cannot
rely on the use of semaphore names longer than _POSIX_PATH_MAX (or
_XOPEN_PATH_MAX on XSI systems), or that have pathname components
longer than _POSIX_NAME_MAX (or _XOPEN_NAME_MAX on XSI systems), so the
simplest solution is just to make ENAMETOOLONG a "may fail" for
exceeding these minimum limits. I believe this would make the standard
reflect what happens in current implementations and applications in
practice.
For application writers that wish to take advantage of longer semaphore
names on systems that support them, and don't mind their applications
being non-portable as a result, we can make the actual limits be
implementation-defined (thus requiring them to be documented).
An alternative solution would be to introduce new _SC_* constants so
that the appropriate values for semaphore names can be obtained from
sysconf(), for example _SC_SEM_NAME_MAX and _SC_SEM_PATH_MAX. On a
system that places semaphores in the file system under
"/var/semaphores", sysconf() could internally do the equivalent of a
call to pathconf("/var/semaphores", _PC_NAME_MAX) to obtain the value.
On systems where slash characters other than the leading slash are not
treated as separating pathname components, sysconf(_SC_SEM_NAME_MAX)
would return -1 without setting errno.
Finally, there is another problem that is not a technical issue, but
relates to the wording on the sem_open() page. The statement "The
interpretation of slash characters other than the leading slash
character in name is implementation-defined" is clearly intended as
an exception to the construction rules for pathnames when they are
applied to semaphore names, since the meaning of non-leading slash
characters is defined by the construction rules for pathnames (see
XBD6 section 3.266: "It has an optional beginning slash, followed by
zero or more filenames separated by slashes."). The text needs to be
rearranged to join these two statements with "except that" to make
this clear.
Also, the requirement to return ENAMETOOLONG when a pathname component
is longer than {NAME_MAX} conflicts with the statement about
interpretation of slash characters other than the leading slash.
Note that all of these issues also affect message queue names. Once a
decision has been made on how to correct the sem_open() page, equivalent
corrections should be made for mq_open().
Action:
On line 39878 change:
"The name argument conforms to the construction rules for a pathname."
to:
"The name argument conforms to the construction rules for a pathname,
except that the interpretation of slash characters other than the
leading slash character in name is implementation-defined, and that
the length limits for the name argument are implementation-defined
and need not be the same as the pathname limits {PATH_MAX} and
{NAME_MAX}."
On lines 39881-39882 delete:
"The interpretation of slash characters other than the leading slash
character in name is implementation-defined."
Delete lines 39905-39907:
"[ENAMETOOLONG]
The length of the name argument exceeds {PATH_MAX} or a
pathname component is longer than {NAME_MAX}."
After line 39910 add:
"If any of the following conditions occur, the sem_open( ) function
may return SEM_FAILED and set errno to the corresponding value:
[ENAMETOOLONG]
The length of the name argument exceeds _POSIX_PATH_MAX on
systems that do not support the XSI option [XSI]or
exceeds _XOPEN_PATH_MAX on XSI systems[/XSI], or has a
pathname component that is longer than _POSIX_NAME_MAX on
systems that do not support the XSI option [XSI]or
longer than _XOPEN_NAME_MAX on XSI systems[/XSI]."
If these proposed changes are accepted, also make equivalent changes to
the mq_open() page.
|