MR https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/1250 was
done in order to try and patch out an `EINVAL` error, and it was
successful in doing so. Unfortunately, fixing one failure caused
another.
I will continue to do what I can to make relibc's FS layer and redoxFS
smaller, as they have way too much duplicated code.
Additionally, this adds the `SYMLOOP_MAX` constant in `limits.h` to
replace the `MAX_LEVEL` magic number used during symlink resolution.
`fstat` was kept because it is more difficult than the others to do a
drop-in replacement in terms of `fstatat` for since a naive approach
would cause mutual recursion.
Inside of `openat2`, we are assuming that if we are passed
`AT_SYMLINK_NOFOLLOW` that we are also passed a symlink. This is simply
not the case, as POSIX defines the flag to only have a noticable effect
if the resolved path is a symlink. Therefore, we cannot assume that we
have a symlink if we see `AT_SYMLINK_NOFOLLOW`. The previous behavior
caused an `EINVAL` in redoxfs because we do a consistency check to
error out if we are passed `O_SYMLINK` (which was added because
`AT_SYMLINK_NOFOLLOW` was observed) and aren't a symlink.
Hmm, maybe a special errno like `ENOTLNK` should be deployed for this? It's
specific enough that it could possibly be added to a future POSIX.
Most of these changes are very simple. Among the changes made involve
taking advantage of auto-deref (`(*val).foo()` -> `val.foo()`) and
removing instances where we create a ref and immediately dereference it
(`&*val` -> `val`). There was a pretty neat case in `posix_openpt` where
some pointer verbosity was able to be reduced by using the more modern C
strings rather than the byte strings with an explicit NUL at the end.
Additionally, `exit()` now calls `unreachable!()` at the end. We
previously did `loop {}`, but clippy didn't like this. It can be up for
debate whether we want to make this `unreachable_unchecked` or similar.
There is only one change that might cause any sort of concern, and that
is the change from `.skip_while(!p).next()` -> `.find(p)`. This, like
everything else, was caught in a Clippy lint but I believe it deserves
some explanation because it isn't immediately obvious. Info about the
lint is here: https://rust-lang.github.io/rust-clippy/rust-1.89.0/index.html#skip_while_next
Connor-GH