stdlib makes assumptions about errors returned by POSIX functions

[tavianator]

Split off from rust-lang/miri#1981 (comment)

For example, we assume that the return value of pthread_rwlock_rdlock() is either 0, EAGAIN, or EDEADLK:

rust/library/std/src/sys/unix/rwlock.rs

Lines 51 to 54 in ac470e9

	// According to POSIX, for a properly initialized rwlock this can only
	// return EAGAIN or EDEADLK or 0. We rely on that.
	debug_assert_eq!(r, 0);
	self.num_readers.fetch_add(1, Ordering::Relaxed);

And that's kinda what POSIX documents: https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_rwlock_rdlock.html

RETURN VALUE

If successful, the pthread_rwlock_rdlock() function shall return zero; otherwise, an error number shall be returned to indicate the error. ...

ERRORS

... The pthread_rwlock_rdlock() and pthread_rwlock_tryrdlock() functions may fail if:

[EAGAIN]
The read lock could not be acquired because the maximum number of read locks for rwlock has been exceeded.

The pthread_rwlock_rdlock() function may fail if:

[EDEADLK]
A deadlock condition was detected or the current thread already owns the read-write lock for writing.

These functions shall not return an error code of [EINTR].

But the thing is, POSIX error sections are not exhaustive: https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_03

Implementations may generate error numbers listed here under circumstances other than those described, if and only if all those error conditions can always be treated identically to the error conditions as described in this volume of POSIX.1-2017. Implementations shall not generate a different error number from one required by this volume of POSIX.1-2017 for an error condition described in this volume of POSIX.1-2017, but may generate additional errors unless explicitly disallowed for a particular function.

And even the docs for that function mention "shall not return an error code of [EINTR]" rather than "shall not return any other error code". So unless there's limits documented elsewhere, I don't think it's sound to assume that there can't be another error code returned from these functions.

CC: @RalfJung

[RalfJung]

Cc @rust-lang/libs

[cuviper]

In general, we should be bubbling up errors that we can't otherwise handle. In this specific instance where we aren't returning Result, we should probably promote that debug assert to a real assert, with a message like "unexpected error: {:?}". If there are others like this, let's treat them on a case-by-case basis.

[kckeiks]

@rustbot claim