The mtx_init(mtx_t *mtx, int type) function is described in §220.127.116.11 of C11 as follows:
-2- The mtx_init function creates a mutex object with properties indicated by type, which must have one of the six values:
- mtx_plain for a simple non-recursive mutex,
- mtx_timed for a non-recursive mutex that supports timeout,
- mtx_plain | mtx_recursive for a simple recursive mutex, or
- mtx_timed | mtx_recursive for a recursive mutex that supports timeout.
-3- If the mtx_init function succeeds, it sets the mutex pointed to by mtx to a value that uniquely identifies the newly created mutex.
Returns -4- The mtx_init function returns thrd_success on success, or thrd_error if the request could not be honored.
Two of the questions raised by DR 493 are the following:
-3- What is the [mtx_init] function's behavior when called with the same pointer more than once (without a call to mtx_destroy() in between)?
-4- What is the function's behavior when called with a pointer to a locked mutex object?
The committee's response is that:
-3- It is undefined behavior to call mtx_init() on memory without an intervening mtx_destroy.
-4- It is undefined behavior to call mtx_init() on memory without an intervening mtx_destroy regardless of the lock condition.
This response is not supported by any text in the standard. Not only is tere no such text in §18.104.22.168, there is no reference to section §7.26 Threads anyhere in §J.2 Undefined behavior. This suggests that the behavior of the function in this case in merely unspecified and not undefined.
Add the following paragraph to §22.214.171.124 before the Returns paragraph:
In addition, add a bullet to §J.2 Undefined behavior referencing the undefined behavior that results from calling the mtx_init function on an already initialized mutex.