[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: routing socket rou(n)ding?
On Feb 18, 2012, at 10:49 AM, Mouse wrote:
> As for "search[ing] for both macro names", I have no convenient way to
> do that; I do not have Linux source on hand.
>>> (c) Your citing this in response to my question implies that Linux
>>> runs on something with sizeof(long) not a power of two. Now I'm
>>> also curious what CPU (and/or machine) that is.
>> A DEC PDP-7 had an 18-bit word size, and the PDP-10 had a 36-bit word
>> size; I'm not sure you'll find anything much newer than that.
> What do those have to do with sizeof(long)?
I don't have a PDP-7 or -10 to test on, and I seem to recall that they had
9-bit chars, so maybe sizeof(long) on them would be 2 and 4, rather than 3 and
5...but it was the closest relevant thing which came to mind.
> You write that the NetBSD macro resembles
> #define RT_ROUNDUP2(a, n) ((a) > 0 ? (1 + (((a) - 1) | ((n) - 1))) :
> #define RT_ROUNDUP(a) RT_ROUNDUP2((a), sizeof(uint64_t))
> which is basically the same thing, except it uses uint64_t; presumably
> this refers to NetBSD newer than anything I have at hand (I haven't
> tracked NetBSD source at all since the GPLv3 was accepted).
I took it from:
> This is technically still at risk, since, even though all divisors of 64 are
> powers of two, uint64_t may include padding bits - for example, on a
> 22-bit machine, uint64_t could have 64 significant bits and 2 padding
> bits and thus (depending on the implementors' choice for char) have
> sizeof(uint64_t) equal something like 6. (Or not provide uint64_t at
> all, since 64 bits is not a native size; that at least would fail to
> compile rather than just silently producing weird rounding.)
C99 says that something which provides a typedef for int64_t / uint64_t needs
to guarantee exactly that 64 bits are available, with no padding, and that the
signed type uses 2's complement representation. This implies that a PDP-7 or
-10 would not have uint64_t available, so I agree with your point that it ought
to fail to compile on such a platform.
>> However, my reason for citing the above is that many variants of
>> ROUNDUP / ROUND_UP are buggy,
> Including all the ones cited so far, on any architecture where the
> relevant sizeof() is not a power of two. (Well, possibly-buggy. The
> RT_ROUNDUP2() above does round up, even when n is not a power of two;
> it just does so rather peculiarly and not very usefully.) That's why I
> was wondering whether any such system with anything like the BSD
> routing socket existed, and, if so, what choice its designers had made
> for dealing with the issue.
FreeBSD 4 used very nearly the same macros in rt_xaddrs(), rt_msg1(), and
rt_msg2(); and that was rewritten in FreeBSD 5:
Main Index |
Thread Index |