Return codes of libc functions are checked for errors only in debug mode.

In libstd/sys/unix there are numerous cases where return code is checked for
error using following pattern:

let result = libc::pthread_mutexattr_init(&mut attr as *mut _);
debug_assert_eq!(result, 0);

That means, that error checking is performed only when compiled in
non-optimized mode or after explicitly enabling debug assertions. This is a
little bit worrying, especially when used on platforms where those functions
can indeed fail and break safety.

[eefriedman]

(For anyone who was confused by the given example, pthread_mutexattr_init can fail with ENOMEM.)

On some platforms types like pthread_mutex_t, pthread_cond_t, etc., are "fat"
structures that have sufficient size to hold everything necessary and their
initialization will never fail (unless initialized incorrectly). But on others
they are opaque pointers to void* and require an additional memory
allocation. Search for those typedefs in libc crate, gives a rough
approximation of affected platforms.

Sadly this also affects static mutexes, so even lock / unlock could potentially
fail. Either way you could end up with a mutex which is not mutually exclusive at
all.

[tmiasko]

When mutex initialization fails this leads to non-functioning mutex and unsoundness.

The pthread_mutex_lock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that.

@rustbot modify labels: C-bug I-unsound