View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000871 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2014-08-26 16:51 | 2020-04-16 15:20 |
| Reporter | shware_systems | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Omission |
| Status | Closed | Resolution | Duplicate | ||
| 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 | See 0000871:0002400. | ||||
| Summary | 0000871: 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
Although we agree that EAGAIN or ERANGE (as used in semop()) might be better choices for this error, at least one implementation already uses EOVERFLOW for this condition. We didn't find a compelling reason to change existing practice. Add to the sem_post() ERRORS section after P1837, L59190: [EOVERFLOW] The semaphore value would exceed {SEM_VALUE_MAX}. |
|
|
As SEM_VALUE_MAX now referenced, suggest at Line 59201, Change: XBD Section 4.11 (on page 110), <semaphore.h> to: XBD Section 4.11 (on page 110), <semaphore.h>, <limits.h> |
|
|
The final accepted text has been updated to fix the issue noted in 0000871:0002401. |
|
|
I reacted too soon. Please disregard 0000871:0002402. The SEE ALSO list doesn't need to be updated for SEM_UNDO_MAX because this value by being enclosed in braces is clearly a limit that would be found in <limits.h> and an application does not need to know the value of that limit to use sen_post(). The change to the SEE ALSO section has been removed from the final accepted text. |
|
|
This is a duplicate of bug 0000315. I believe 315 should stand and this one should be closed as a dup of it, since 315 is an approved interpretation and it adds EOVERFLOW as a "shall fail" whereas this bug (incorrectly in my view) adds it as a "may fail". |
|
|
This was discussed in the April 16th, 2020 teleconference and the meeting decided that bug 0000315 was correct in adding EOVERFLOW to the "shall fail" section and this bug was incorrect in adding it to "may fail". Therefore the consensus is that this should be closed as a duplicate of 315. |
| 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 | |
| 2014-10-02 17:00 | Don Cragun | Interp Status | => --- |
| 2014-10-02 17:00 | Don Cragun | Note Added: 0002400 | |
| 2014-10-02 17:00 | Don Cragun | Status | New => Resolved |
| 2014-10-02 17:00 | Don Cragun | Resolution | Open => Accepted As Marked |
| 2014-10-02 17:01 | Don Cragun | Final Accepted Text | => See 0000871:0002400. |
| 2014-10-02 17:02 | Don Cragun | Tag Attached: issue8 | |
| 2014-10-02 17:02 | Don Cragun | Note Edited: 0002400 | |
| 2014-10-02 17:06 | Don Cragun | Note Edited: 0002400 | |
| 2014-10-02 17:07 | Don Cragun | Note Edited: 0002400 | |
| 2014-10-02 17:10 | shware_systems | Note Added: 0002401 | |
| 2014-10-02 17:30 | Don Cragun | Note Edited: 0002400 | |
| 2014-10-02 17:31 | Don Cragun | Note Added: 0002402 | |
| 2014-10-02 17:40 | Don Cragun | Note Added: 0002403 | |
| 2014-10-02 17:41 | Don Cragun | Note Edited: 0002400 | |
| 2014-10-02 17:42 | Don Cragun | Note Edited: 0002403 | |
| 2020-04-02 09:14 | geoffclare | Note Added: 0004810 | |
| 2020-04-02 09:14 | geoffclare | Relationship added | duplicate of 0000315 |
| 2020-04-16 15:20 | geoffclare | Note Added: 0004825 | |
| 2020-04-16 15:20 | geoffclare | Status | Resolved => Closed |
| 2020-04-16 15:20 | geoffclare | Resolution | Accepted As Marked => Duplicate |
| 2020-04-16 15:22 | geoffclare | Tag Detached: issue8 |
