Re: routing socket rou(n)ding?

[Chuck Swiger <cswiger%mac.com@localhost>]

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.

Does:

  http://fxr.watson.org/fxr/ident?i=ROUNDUP,ALIGN
  http://fxr.watson.org/fxr/trackident?i=ROUNDUP
  http://fxr.watson.org/fxr/trackident?i=ALIGN

...help?

>>> (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))) : 
> (n))
> #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:

   http://fxr.watson.org/fxr/source/net/route.h?v=NETBSD#L270

> 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:

  http://fxr.watson.org/fxr/source/net/rtsock.c?v=FREEBSD4#L520
  http://fxr.watson.org/fxr/source/net/rtsock.c?v=FREEBSD5#L617

Regards,
-- 
-Chuck