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