Terry Lambert wrote:
src/sys/kern/uipc_sem.c, version 1.3:Get me the exact file you are concerned about, and I will stare at it with you. I think, though, that if there is a problem, it's just that you are catching things in mid-implementation (POSIX semaphores were supported in the other scope, but not system, until very recently; there's even magic POSIX manifests that tell you not to use them).
...
#define SEM_MAX_NAMELEN 14
...
static int
sem_create(td, name, ksret, mode, value)
...
if (value > SEM_VALUE_MAX)
return (EINVAL);
ret = malloc(sizeof(*ret), M_SEM, M_WAITOK | M_ZERO);
if (name != NULL) {
len = strlen(name);
if (len > SEM_MAX_NAMELEN) {
free(ret, M_SEM);
return (ENAMETOOLONG);
}
/* name must start with a '/' but not contain one. */
if (*name != '/' || len < 2 || index(name + 1, '/') != NULL) {
free(ret, M_SEM);
return (EINVAL);
}
The comment makes it look like this code allows a 14-character named semaphore which *must* start with a slash and cannot contain embedded slashes. In other words, it does *not* conform to pathname semantics.
If some other part of the system already verifies that the named semaphore is actually an empty directory entry, then why is there a name length restriction and why is there a '/' check?
If this is a bug, I will happily submit a PR. I wanted some feedback before doing so. I am interested in playing with the semantics of posix semaphores. It looks to me as though they could be implemented more resource-efficiently than SVID semaphores and really do have different semantics. I really want to try to understand what will and won't be released in 5.0. How will I enable these for testing/use and will they work in a portable way? The only way to answer those questions right now is to examine the source. I am trying to understand the source, especially in how it may or may not restrict use of semaphores.
/Joe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
