[Toybox] this week in weird coreutils stuff: chmod

enh enh at google.com
Thu May 30 12:59:45 PDT 2024


funnily enough, i'm having exactly this argument with the person who
asked for this chmod functionality, since they own the ABI checker,
and i'm claiming that telling me that i've "changed" u_int32_t to
uint32_t is not helpful, and that when talking about ABI i always want
the underlying type :-)

On Thu, May 30, 2024 at 3:41 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> 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


More information about the Toybox mailing list