Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: msync on Hurd, dev_t on MIPS (Julien ?LIE)
2. Re: msync on Hurd, dev_t on MIPS (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Apr 2016 23:13:11 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: msync on Hurd, dev_t on MIPS
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Following a very old discussion (2009/11/03)...
Russ Allbery wrote:
>> Debian build of INN 2.5.1
>
>> On MIPS, we have:
>
>> hisv6/hisv6.c: In function 'hisv6_closefiles':
>> hisv6/hisv6.c:272: warning: large integer implicitly truncated to unsigned
>> type
>> hisv6/hisv6.c: In function 'hisv6_new':
>> hisv6/hisv6.c:480: warning: large integer implicitly truncated to unsigned
>> type
>
>> It corresponds to the cast to dev_t:
>> h->st.st_dev = (dev_t)-1;
>
>> How can we change that?
>
> That's an odd one. I'm not sure what to make of that error. It sounds
> almost like st_dev isn't a dev_t, but that doesn't make any sense to me.
> You should be able to cast -1 to an unsigned type; that's a common C
> idiom.
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.
--
Julien ?LIE
? ?tre ?u ne p?s ?tre, telle est l? questi?n? ? (Ker?zen)
------------------------------
Message: 2
Date: Fri, 15 Apr 2016 14:42:12 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: msync on Hurd, dev_t on MIPS
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> 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 ([email protected]) <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.
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 83, Issue 7
******************************************
