There are a few issues with Plan 9's `access`:
- it has side effects: to test the actual access (that the file
servers can allow or deny according to complex custom rules)
it opens and then closes the file, allocating (and disposing) the fd
- it does not work on directories, since
- they cannot be opened for writing, despite the fact that to
create a file in a directory you must be granted write access on
that directory
- they cannot be opened for execution, despite the fact that to
access a file in a directory you must be granted execution access
on that directory
Despite the fact that `access` (even on UNIX) is a violation of the
"tell, don't ask" principle (the access could be forbidden just after
its successful return, making subsequent `open` fail anyway), this
fact smells of a little design error in the file interface.
So, right now we choose to let the libposix's `access` lie on directories:
it will always return 0 on AWRITE and AEXEC for them, accepting that
a successive create/mkdir may fail.
However, a cleaner file API and protocol should allow a simpler `access`
to be implemented for directories too.
The img_get macro used to subtract 1 to the argument provided before
computing the porinter to the image. I can't remember why it did so.
However the expression was wrong.
Coverity found the issue:
Operands don't affect result (CONSTANT_EXPRESSION_RESULT)
CID: 155616, 155606, 155598, 155597, 155596, 155587,
155580, 155578, 155577, 155576, 155568, 155566
Simply removing the subtraction seems the obvious fix.
