The is_writeable, is_readable and is_executable functions
make the assumption that all permissions on POSIX systems
will be limited to UID/GID masks applied to the current
process UID and GID.

The particular application where this is biting me is accessing
files on an XFS filesystem.  On top of the plain old
file permissions, which by default give the webserver UID/GID
access to a whole swag of files, several files are specifically
excluded from the webserver UID/GID using POSIX ACL's such as:

  chuckles:/mnt/archive$ getfacl somefile
  # somefile: 002-asdf/
  # owner: danpat
  # group: users
  user::rwx
  group::r--
  other::r--
  group:www-data:---

The user "www-data" under which the webserver runs is a member
of both the "users" group and the "www-data" group.  This
ACL means that members of the "users" group who are no also
members of the "www-data" group can read the file, but people
who are in both groups may not.

For this case, calculating the bitmasks is not enough to determine
the correct result.

I note that the PHP code uses the stat() function to obtain
the file permissions and calculates the permissions itself.

There is an alternative function in access(2) which can be
used to obtain the readability, writeability and executability
of a file in a way such as:

  #include <unistd.h>

  int is_writeable(const char *filename) {
    return access(filename, W_OK);
  }

  int is_readable(const char *filename) {
    return access(filename, R_OK);
  }

  int is_executable(const char *filename) {
    return access(filename, X_OK);
  }

I believe something like this is probably more inline with what
the is_readable, is_writeable and is_executable function are
trying to achieve.  Currently, they're returning the mask of
the process UID/GID and the file mask, however, this isn't always
100% accurate (i.e. if running as the superuser, is_readable
is almost always true, even if the file permissions say otherwise).