[1003.1(2013)/Issue7+TC1 0000871]: Missing potential error code, EOVERFLOW

[Austin Group Bug Tracker]

The following issue has been SUBMITTED.
======================================================================
http://austingroupbugs.net/view.php?id=871
======================================================================
Reported By: shware_systems
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 871
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
Status: New
Name: Mark Ziegast
Organization: SHware Systems Development
User Reference:
Section: sem_getvalue, sem_post, sem_*wait
Page Number: many
Line Number: 58951, 59170, others
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-26 16:51 UTC
Last Modified: 2014-08-26 16:51 UTC
======================================================================
Summary: Missing potential error code, EOVERFLOW
Description:
In looking over reports 869, 870 I noticed that the sem_post() interface
requires an int value be incremented, but does not provide an application a
means of detecting arithmetic overflow of that value, when the SIGFPE
signal is blocked, in a way distinguishable from an attempt to use an
uninitialized sem_t record, currently reported by the EINVAL error code.
While this may be a corner case usually encountered only when an
application has an infinite loop containing a sem_post() call, not
detecting it may cause threads to spuriously unblock, by increment to 0, or
sem_getvalue to return an invalid waiting processes count.

Whether this should be a sticky case, requiring the semaphore be
reinitialized before other access attempts succeed, or what other side
effects should be required behavior I feel needs discussion, so Desired
Action sparse.
Desired Action:
Add to the Error Codes section of the related interfaces:

[EOVERFLOW] The semaphore count was incremented past INT_MAX,
invalidating the semaphore usage.

Additional language about usage caveats, historical practice, signal
interactions, etc.
======================================================================

Issue History
Date Modified Username Field Change
======================================================================
2014-08-26 16:51 shware_systems New Issue
2014-08-26 16:51 shware_systems Name => Mark Ziegast
2014-08-26 16:51 shware_systems Organization => SHware Systems
Development
2014-08-26 16:51 shware_systems Section => sem_getvalue,
sem_post, sem_*wait
2014-08-26 16:51 shware_systems Page Number => many
2014-08-26 16:51 shware_systems Line Number => 58951, 59170,
others
======================================================================

[Austin Group Bug Tracker]

A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=871
======================================================================
Reported By: shware_systems
Assigned To:
======================================================================
Project: 1003.1(2013)/Issue7+TC1
Issue ID: 871
Category: System Interfaces
Type: Omission
Severity: Comment
Priority: normal
Status: New
Name: Mark Ziegast
Organization: SHware Systems Development
User Reference:
Section: sem_getvalue, sem_post, sem_*wait
Page Number: many
Line Number: 58951, 59170, others
Interp Status: ---
Final Accepted Text:
======================================================================
Date Submitted: 2014-08-26 16:51 UTC
Last Modified: 2014-08-27 00:35 UTC
======================================================================
Summary: Missing potential error code, EOVERFLOW
======================================================================

----------------------------------------------------------------------
(0002365) dalias (reporter) - 2014-08-27 00:35
http://austingroupbugs.net/view.php?id=871#c2365
----------------------------------------------------------------------
I would strongly prefer that, if sem_post fails, there should be no change
to the semaphore value. Declaring the semaphore object unusable is no
better, from an application perspective, than the current situation where
the result is simply not defined; there will rarely be any reasonable way
an application could recover from a no-longer-usable synchronization object
once it has started using it for synchronization.

Since pthread_mutex_lock uses EAGAIN for the equivalent condition on
recursive mutexes, there is some question as to which error code should be
preferred. I mildly prefer EAGAIN since EOVERFLOW seems to imply that an
overflow already occured, rather than that the operation cannot be
performed because an overflow would occur. If there is disagreement on the
above semantics though (whether the semaphore is usable after overflow),
perhaps both could be specified, with EOVERFLOW meaning that the semaphore
has overflowed and is no longer usable, and EAGAIN meaning that the post
cannot be performed because it would overflow (and the semaphore is still
in a usable state). This would leave both choices open to implementations
while letting applications know which behavior they got.

Issue History
Date Modified Username Field Change
======================================================================
2014-08-26 16:51 shware_systems New Issue
2014-08-26 16:51 shware_systems Name => Mark Ziegast
2014-08-26 16:51 shware_systems Organization => SHware Systems
Development
2014-08-26 16:51 shware_systems Section => sem_getvalue,
sem_post, sem_*wait
2014-08-26 16:51 shware_systems Page Number => many
2014-08-26 16:51 shware_systems Line Number => 58951, 59170,
others
2014-08-27 00:35 dalias Note Added: 0002365
======================================================================