View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001404 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2020-09-24 00:44 | 2024-06-11 09:08 |
| Reporter | dalias | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Rich Felker | ||||
| Organization | musl libc | ||||
| User Reference | |||||
| Section | pthread_mutex_destroy | ||||
| Page Number | (page or range of pages) | ||||
| Line Number | (Line or range of lines) | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001404:0005232 | ||||
| Summary | 0001404: Is there a requirement to destroy mutex before object lifetime ends? | ||||
| Description | The specification of pthread_mutex_destroy establishes conditions under which behavior of call to pthread_mutex_destroy is undefined, but does not cover whether there are conditions under which failure to call it is undefined. If the lifetime of a pthread_mutex_t object with automatic or allocated storage duration (or mmap/MAP_ANON) ends (end of execution of block, call to free, munmap, etc.) without a call to pthread_mutex_destroy, is or should the behavior be undefined? I tend to believe it should be undefined, because the intent of having init/destroy functions seems to be to allow implementation flexibility that would include things like keeping a linked list of all existant objects for error-checking (necessary for diagnostic of double init, etc.), using allocation in pthread_mutex_init (in which failure to call pthread_mutex_destroy is a memory leak, which although not inherently fatal, is bad), and so on. | ||||
| Desired Action | Possibly add text to description: "If the lifetime of an initialized pthread_mutex_t object ends without a call to pthread_mutex_destroy, the behavior is undefined." It's likely that this proposal needs further discussion, particularly for the case of process-shared objects living in MAP_SHARED (and maybe also MAP_ANON) memory where the end of the object lifetime is not well-defined, and where it may be desirable to allow omission of pthread_mutex_destroy because of software that relies on the shared memory ceasing to exist when the last user unmaps it. If an action is taken on this, similar actions are probably needed for other pthread object types. | ||||
| Tags | tc3-2008 | ||||
|
|
On page 471 line 16206 section 2.1.1, change:If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined.to: If an argument to a function has an invalid value, such as a value outside the domain of the function, a pointer to an object whose lifetime has ended (even if a new object now has the same address), a pointer outside the address space of the program, or a null pointer, the behavior is undefined. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-09-24 00:44 | dalias | New Issue | |
| 2020-09-24 00:44 | dalias | Name | => Rich Felker |
| 2020-09-24 00:44 | dalias | Organization | => musl libc |
| 2020-09-24 00:44 | dalias | Section | => pthread_mutex_destroy |
| 2020-09-24 00:44 | dalias | Page Number | => (page or range of pages) |
| 2020-09-24 00:44 | dalias | Line Number | => (Line or range of lines) |
| 2021-02-11 16:37 | geoffclare | Note Added: 0005232 | |
| 2021-02-11 16:38 | geoffclare | Interp Status | => --- |
| 2021-02-11 16:38 | geoffclare | Final Accepted Text | => 0001404:0005232 |
| 2021-02-11 16:38 | geoffclare | Status | New => Resolved |
| 2021-02-11 16:38 | geoffclare | Resolution | Open => Accepted As Marked |
| 2021-02-11 16:38 | geoffclare | Tag Attached: tc3-2008 | |
| 2021-03-08 15:19 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 09:08 | agadmin | Status | Applied => Closed |
