<div dir="ltr"><div><div>> If it really bothers you, I can change it back. It just makes the rangetest... sort of inconclusive.<br><br></div>Nah doesn't bother me at all. I was just curious and looking to learn about some of these C/linux intricacies.<br></div>Thanks for the details!<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-20 22:46 GMT+02:00 Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/20/2016 06:01 AM, darken wrote:<br>
>     I was grinding through my todo list last night and fixed this, and only<br>
>     just noticed replying to your message that you'd attached a patch.<br>
>     (Oops. Sorry.)<br>
><br>
><br>
> :-|, well at least it's fixed.<br>
><br>
>     The fixes look fairly similar. I need to update tests/chown.test and<br>
><br>
>     tests/chgrp.test to actually check for this usefully. (Poking at<br>
>     that now.)<br>
><br>
><br>
> Why return `unsigned` instead of `uid_t`/`gid_t` from the get uid/gid<br>
> methods?<br>
<br>
</span>Because it's hard to range check otherwise.<br>
<br>
Unsigned int is the underlying type in uid_t these days (there's a<br>
getuid32 and everything), and if somebody tries to select a numeric uid<br>
out of range I want to catch that rather than wrapping it. I dunno off<br>
the top of my head what the UID_T_MAX macros would be (didn't find one<br>
in<br>
<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html" rel="noreferrer" target="_blank">http://pubs.opengroup.org/<wbr>onlinepubs/009695399/basedefs/<wbr>sys/stat.h.html</a><br>
and similar), and 1LL<<8*sizeof(x) is just awkward (and assumes it's<br>
unsigned, which it _is_ but I'm not sure it's _required_ to be?)<br>
<br>
I have a tendency to squash things to known types and operate on them,<br>
producing behavior that's at least consistent. Possibly inappropriate in<br>
this case...<br>
<br>
On old Linux systems you had 16 bit uid ranges, but that went away<br>
before the posix 2008 (openat) stuff went in, so I think we already<br>
don't support such systems. Ok, it's still a build config option in the<br>
kernel, CONFIG_UID16, but so is CONFIG_BINFMT_AOUT a.out binary support.<br>
<br>
And then there's the discussion of 65534 being the _other_ magic UID<br>
number in the kernel. uid is 0, nobody is 65534, and the kernel knows<br>
both: <a href="https://lwn.net/Articles/695478/" rel="noreferrer" target="_blank">https://lwn.net/Articles/<wbr>695478/</a><br>
<br>
Legacy from the 16 bit UID days.<br>
<br>
If it really bothers you, I can change it back. It just makes the range<br>
test... sort of inconclusive.<br>
<span class=""><br>
> By the way, I have another patch for the test applet:<br>
> <a href="https://github.com/landley/toybox/pull/47" rel="noreferrer" target="_blank">https://github.com/landley/<wbr>toybox/pull/47</a><br>
</span>> <<a href="https://github.com/landley/toybox/pull/47" rel="noreferrer" target="_blank">https://github.com/landley/<wbr>toybox/pull/47</a>><br>
<br>
Test is in pending for a reason, but I'll take a look at this after I<br>
finish adding tunctl and promoting getfattr/setfattr. (Much reading on<br>
how xattrs work. Whoever designed these APIs should be harmed.)<br>
<br>
Thanks,<br>
<br>
Rob<br>
</blockquote></div><br></div>