sem_post() overflow

[Hallvard B Furuseth]

Why doesn't the sem_post() description say what happens on overflow?
No defined error, nor does it block. I guess that leaves the behavior
undefined. If that's intentional I think it should be spelled out.
OTOH sem_init() fails with EINVAL on if value > {SEM_VALUE_MAX}.
sem_post() EINVAL for another error; it it should error on overflow
I guess it should use ERANGE.

How can a program avoid the problem, if it wants more than
_POSIX_SEM_VALUE_MAX posts before wait? sysconf(_SC_SEM_VALUE_MAX)
returns a semaphore value the program can take care not to exceed,
but that setting is configurable. After the program reads that
limit, can something reduce the limit so the program fails anyway?

[Geoff Clare]

Post by Hallvard B Furuseth
Why doesn't the sem_post() description say what happens on overflow?
No defined error, nor does it block. I guess that leaves the behavior
undefined. If that's intentional I think it should be spelled out.

I don't think the behaviour is undefined. I think there are two
allowed behaviours:

1. sem_post() fails and returns -1 with errno set to some appropriate
value. This is allowed by the general rule for additional errors in
XSH7 section 2.3 "Error Numbers".

2. sem_post() "succeeds" and returns 0. I.e. it performs the
increment operation. The question then is what is the result
of the increment operation? XBD7 section 4.16 "Semaphore" says
the semaphore is "represented as a shareable resource that has a
non-negative integer value." Since it doesn't specify whether
the integer is signed or unsigned, implementations could use
either. If it is unsigned, the result of the increment operation
is zero. If it is signed, the result is (if I'm remembering
what C99 says correctly) either an implementation-defined value
or the generation of an implementation-defined signal.

In case 1, SEM_VALUE_MAX could be less than the maximum value
representable in the integer used to hold the semaphore value.
In case 2, SEM_VALUE_MAX has to be equal to the maximum
representable value, otherwise sem_post() would be able to
increment the semaphore a greater value, violating the definition
of SEM_VALUE_MAX.

Post by Hallvard B Furuseth
OTOH sem_init() fails with EINVAL on if value > {SEM_VALUE_MAX}.
sem_post() EINVAL for another error; it it should error on overflow
I guess it should use ERANGE.

ERANGE and EOVERFLOW are the most likely choices if sem_post() fails,
but implementations could choose other error numbers (including
non-standard ones) as long as they follow the rules in XSH7 section
2.3.

Post by Hallvard B Furuseth
How can a program avoid the problem, if it wants more than
_POSIX_SEM_VALUE_MAX posts before wait? sysconf(_SC_SEM_VALUE_MAX)
returns a semaphore value the program can take care not to exceed,
but that setting is configurable. After the program reads that
limit, can something reduce the limit so the program fails anyway?

No. The RETURN VALUE section on the sysconf() page says:

"The value shall not change during the lifetime of the calling
process, except that sysconf(_SC_OPEN_MAX) may return different
values before and after a call to setrlimit() which changes the
RLIMIT_NOFILE soft limit."

This assumes the application uses only standard interfaces - if it
uses an extension which lowers SEM_VALUE_MAX, then of course this
guarantee for sysconf() no longer applies. (That is how POSIX.1-1990
implementations could have sysconf(_SC_OPEN_MAX) return a different
value if the application used setrlimit() with RLIMIT_NOFILE,
because setrlimit() was not in POSIX at the time.)