From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: <djgpp-workers AT delorie DOT com>
Subject: POSIX requirements for stat()?
Date: Sat, 26 May 2001 19:31:33 +0200
Message-ID: <CAEGKOHJKAAFPKOCLHDIIEKKCDAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0000_01C0E61A.78A08DA0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Reply-To: djgpp-workers AT delorie DOT com

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C0E61A.78A08DA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Does POSIX require the st_mode field to have a particular
layout, and does it require particular meanings for the
mode bits?

I'm working on porting Python (which will likely require
some work - I'm currently hacking my way around several
problems, which will require a better solution later),
and I hit a problem where a simple existence check was
failing.  As it turns out, the Python 'stat' module
(attached) uses  constants that don't match what DJGPP
puts into struct stat.  So I was wondering if this was
because DJGPP uses non-standard values (in which case
adjusting <sys/stat.h> may be a viable solution), or
whether the module was assuming facts not in evidence
(in which case I'm probably better of transforming
struct stat to the format it expects while it turns it
into a Python object).

------=_NextPart_000_0000_01C0E61A.78A08DA0
Content-Type: application/octet-stream;
	name="stat.py"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="stat.py"

"""Constants/functions for interpreting results of os.stat() and =
os.lstat().=0A=
=0A=
Suggested usage: from stat import *=0A=
"""=0A=
=0A=
# Strictly spoken, this module may have to be adapted for each POSIX=0A=
# implementation; in practice, however, the numeric constants used by=0A=
# stat() are almost universal (even for stat() emulations on non-UNIX=0A=
# systems like MS-DOS).=0A=
=0A=
# Indices for stat struct members in tuple returned by os.stat()=0A=
=0A=
ST_MODE  =3D 0=0A=
ST_INO   =3D 1=0A=
ST_DEV   =3D 2=0A=
ST_NLINK =3D 3=0A=
ST_UID   =3D 4=0A=
ST_GID   =3D 5=0A=
ST_SIZE  =3D 6=0A=
ST_ATIME =3D 7=0A=
ST_MTIME =3D 8=0A=
ST_CTIME =3D 9=0A=
=0A=
# Extract bits from the mode=0A=
=0A=
def S_IMODE(mode):=0A=
    return mode & 07777=0A=
=0A=
def S_IFMT(mode):=0A=
    return mode & 0170000=0A=
=0A=
# Constants used as S_IFMT() for various file types=0A=
# (not all are implemented on all systems)=0A=
=0A=
S_IFDIR  =3D 0040000=0A=
S_IFCHR  =3D 0020000=0A=
S_IFBLK  =3D 0060000=0A=
S_IFREG  =3D 0100000=0A=
S_IFIFO  =3D 0010000=0A=
S_IFLNK  =3D 0120000=0A=
S_IFSOCK =3D 0140000=0A=
=0A=
# Functions to test for each file type=0A=
=0A=
def S_ISDIR(mode):=0A=
    return S_IFMT(mode) =3D=3D S_IFDIR=0A=
=0A=
def S_ISCHR(mode):=0A=
    return S_IFMT(mode) =3D=3D S_IFCHR=0A=
=0A=
def S_ISBLK(mode):=0A=
    return S_IFMT(mode) =3D=3D S_IFBLK=0A=
=0A=
def S_ISREG(mode):=0A=
    return S_IFMT(mode) =3D=3D S_IFREG=0A=
=0A=
def S_ISFIFO(mode):=0A=
    return S_IFMT(mode) =3D=3D S_IFIFO=0A=
=0A=
def S_ISLNK(mode):=0A=
    return S_IFMT(mode) =3D=3D S_IFLNK=0A=
=0A=
def S_ISSOCK(mode):=0A=
    return S_IFMT(mode) =3D=3D S_IFSOCK=0A=
=0A=
# Names for permission bits=0A=
=0A=
S_ISUID =3D 04000=0A=
S_ISGID =3D 02000=0A=
S_ENFMT =3D S_ISGID=0A=
S_ISVTX =3D 01000=0A=
S_IREAD =3D 00400=0A=
S_IWRITE =3D 00200=0A=
S_IEXEC =3D 00100=0A=
S_IRWXU =3D 00700=0A=
S_IRUSR =3D 00400=0A=
S_IWUSR =3D 00200=0A=
S_IXUSR =3D 00100=0A=
S_IRWXG =3D 00070=0A=
S_IRGRP =3D 00040=0A=
S_IWGRP =3D 00020=0A=
S_IXGRP =3D 00010=0A=
S_IRWXO =3D 00007=0A=
S_IROTH =3D 00004=0A=
S_IWOTH =3D 00002=0A=
S_IXOTH =3D 00001=0A=

------=_NextPart_000_0000_01C0E61A.78A08DA0--