Mail Archives: djgpp-workers/1997/11/25/10:02:19
On Tue, 25 Nov 1997, DJ Delorie wrote:
> > S_ISUID is not the main problem. The S_IFMT bits are. Does SGI
> > define these differently as well?
>
> Differently than what?
From other Unix boxes.
> Here's what SGI says:
>
> #define S_IFMT 0xF000 /* type of file */
> #define S_IFIFO 0x1000 /* fifo */
> #define S_IFCHR 0x2000 /* character special */
> #define S_IFDIR 0x4000 /* directory */
> #define S_IFNAM 0x5000 /* XENIX special named file */
> #define S_IFBLK 0x6000 /* block special */
> #define S_IFREG 0x8000 /* regular */
> #define S_IFLNK 0xA000 /* symbolic link */
> #define S_IFSOCK 0xC000 /* socket */
Just tested on SunOS 4.x, Solaris 2.5, Alpha/NetBSD and i486/Linux: they
all have exactly these values. Ours differ.
> The POSIX manual defines specific numeric values that are to be stored
> when certain inode types are described. cpio must convert between the
> system's symbolic constants and the defined standard numeric values
> when it reads/writes the cpio archive. Relying on the constants to
> match the defined numeric values is a bug and should be fixed.
cpio does convert the types when storing the files. What it does NOT do
is to do the reverse conversion when it lists the files. It uses the
type to print a letter in the "ls -l" style, like "drwxr-xr-x", which
identifies the type of the file. The problem is that it does that with
the usual S_ISDIR etc. macros (which in DJGPP test for our native values)
to test the bits that are stored in the archive with POSIX-compatible
values. The assumption here clearly is that the native S_ISfoo macros
coincide with what POSIX specifies for the cpio archive format.
I had to write a DJGPP-specific function to replace the usual GNU
ftypelet function used by cpio, to get the archive listing right.
- Raw text -