[Toybox] this week in weird coreutils stuff: chmod

[Rob Landley]

On 5/29/24 14:20, enh wrote:
> seems to have broken the macOS build?
> ```
> lib/lib.c:953:10: error: conflicting types for 'string_to_mode'
> unsigned string_to_mode(char *modestr, unsigned mode)
>          ^
> ./lib/lib.h:413:10: note: previous declaration is here
> unsigned string_to_mode(char *mode_str, mode_t base);
>          ^
> ```

Oops, missed one. Try commit 3c276ac106a4.

So what _is_ mac using... Sigh:

/Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk/usr/include/sys/_types/_mode_t.h:typedef
__darwin_mode_t         mode_t;
/Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk/usr/include/sys/_types.h:typedef
__uint16_t      __darwin_mode_t;        /* [???] Some file attributes */

They typedef it to unsigned short instead of unsigned int. Even though type
promotion will pass an int on the stack for anything smaller than an int, and
use an int register to do the math...

I guess back in 1974 "int" was a 16 bit type, and they stuck with that in the
move to 32 and then 64 bit processors because SUGO times 3 bits each is only
using 12 of those 16 bits, leaving 4 for file types and we've only used 7 of
those 16 combinations for IFDIR and IFBLK and so on (well, 8 on mac but the
header says IFWHT is obsolete), clearly that will never run out...

*shrug* Removing all uses of mode_t and using "unsigned" instead consistently
should work fine. Only "struct stat" should really care, and even then they
could just use the actual primitive type in the struct definition...

(I'm not a fan of data hiding without some _reason_ for it. I used to humor it a
lot more, but now I want to know what/why it's doing.)

Rob