[Swan] lset_t usage is a mess in Pluto

Paul Wouters paul at nohats.ca
Mon Sep 23 17:43:11 EEST 2013


On Tue, 17 Sep 2013, D. Hugh Redelmeier wrote:

> Someone after me found that they needed more than 32 elements for some
> member type.  So they redefined lset_t to be unsigned long long.
>
> This was a bit brute force: every lset_t became twice as large and, on
> many machines, the operations upon it took twice as many machine
> instructions and register.  I guess that everything is cheap these days,
> so it is kind of OK.

If we split the DBG_ ones from the IMPAIR_* ones, those each would fit
easilly in 32 elements, although I could see the IMPAIR ones exceeding
it again in the future.

We have more then 32 state_kind's, but I don't think those use LELEM?

The one why it got changed originally was the pluto_policy list. We
exceeded 32, although we removed WINS and got back to 31 now. This could
be made shorter if we would split these in two. Some of these policies
are IPSEC policies (ENCRYPT, PFS, TUNNEL, etc) and some are CONNECTION
policies (REKEY, HOST, XAUTH, OPPO, etc). I'm not sure if the gains are
worth the rewrite? I don't think we mixup checking IPSEC vs CONNECTION
policies though?

> Whoever wrote xauth.c seems to have decided to use unsigned int for the
> representation of some sets, but still use the lset_t operators.  And
> didn't document it (actually, there is a tiny bit of documentation that is
> wrong).

Probably a combination of authors :)

> When I created lset_t, one size was enough.  Do we really need all these
> different sizes?  If so, we really ought to have different set types for
> each size (set_t, lset_t, llset_t would mimic C's unsigned types)?  If C
> were more powerful, a set type for each enum would be even cleaner (like
> Pascal).

Your call?

> xauth.c is a bit of a mess anyway.  I'll switch the unsigned int to
> lset_t.

Thanks.

Paul


More information about the Swan mailing list