[MiNT] STAT bits - Ouch!

[Alan Hourihane <alanh@fairlite.co.uk>]

Hi folks,

This problem has been around a long long time.......

Given, pretty much, every unix'ish style OS defines these....

#define __S_IFDIR       0040000 /* Directory.  */
#define __S_IFCHR       0020000 /* Character device.  */
#define __S_IFBLK       0060000 /* Block device.  */
#define __S_IFREG       0100000 /* Regular file.  */
#define __S_IFIFO       0010000 /* FIFO.  */
#define __S_IFLNK       0120000 /* Symbolic link.  */
#define __S_IFSOCK      0140000 /* Socket.  */

On FreeMiNT, we do this....

#define __S_IFDIR       0040000 /* Directory.  */
#define __S_IFCHR       0020000 /* Character device.  */
#define __S_IFBLK       0060000 /* Block device.  */
#define __S_IFREG       0100000 /* Regular file.  */
#define __S_IFIFO       0120000 /* FIFO.  */
#define __S_IFLNK       0160000 /* Symbolic link.  */
#define __S_IFSOCK      0010000 /* Socket.  */

and we have this too...

#define __S_IFMEM       0140000 /* memory region or process */

So, __S_IFDIR, __S_IFCHR and __S_IFBLK are defined the same. But
__S_IFIFO, __S_IFLNK, __S_IFSOCK and __S_IFMEM are not and this is the
problem.

There are at least two programs I know of which expect these to be
defined as above, they are python and git, there may well be others we
haven't noticed. We patch python, but git is not so easily patched.

Now, POSIX doesn't guarantee these values, so we are perfectly able to
have our defines as above, but we get into trouble when applications are
written to these defacto standards.

To fix this, I'm thinking of adding an additional command to Ssystem()
to tell the kernel to interpret these bits differently. Therefore any
new MiNTlib compiled applications would require a new kernel, and if it
doesn't get it, the application would fail instantly with an appropriate
error message. But existing applications would still work with new or
old kernels.

What do people think about this ?

Alan.