msync on Hurd, dev_t on MIPS
Russ Allbery
eagle at eyrie.org
Fri Apr 15 21:42:12 UTC 2016
Julien ÉLIE <julien at trigofacile.com> writes:
> I've just came across that warning again, and found the explanation:
> https://lists.debian.org/debian-mips/2011/11/msg00006.html
> https://lists.debian.org/debian-mips/2015/09/msg00068.html
> "for historical reasons mips (o32) defines struct stat with a 32-bit dev_t
> even though it defines dev_t to be 64-bits. It's been
> defined this way since at least 1997 when mips was added to glibc"
> So we're casting -1 to (unsigned long long) and then assigning it to
> (unsigned long) on MIPS.
> As Russ suggested, changing
> h->st.st_dev = (dev_t)-1;
> to
> h->st.st_dev = (unsigned long)-1;
> fixes the issue, so I'll commit that change.
Unfortunately, that doesn't have the same meaning if dev_t is an unsigned
long long. That takes -1, converts it to an unsigned long (which means
it's now the positive integer ULONG_MAX) and then assigns it to an
unsigned long long field, where it might be a perfectly valid device
identifier in the middle of the available device number range rather than
a sentinel "invalid device" number as intended. :( Chances of a
collision are thankfully minute, but it's not formally correct.
It *shouldn't* matter, because we always compare against st_ino as well,
but the formally correct fix is probably to figure out the size of the
struct stat st_dev field in Autoconf and explicitly cast -1 to that size,
whatever it is.
Not sure if it's worth the trouble, though.
--
Russ Allbery (eagle at eyrie.org) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers
mailing list