[Swan-dev] [Swan-commit] modularity erosion

Paul Wouters paul at nohats.ca
Wed Feb 13 17:32:30 UTC 2019


On Wed, 13 Feb 2019, D. Hugh Redelmeier wrote:

> | /*
> |  * XXX: useful?
> |  */
> | struct ike_proposals {
> |         struct proposals *p;
> | };
> | struct child_proposals {
> |         struct proposals *p;
> | };
>
> This is a nice safety measure/trick.  Not necessarily in this case (I have
> no opinion), but as one of our bag of C tools for making clearer and
> safer code.

Oh, I like it. I also hope to see the struct state in a similar
situation, or even better, be an actual different struct.

(but no hacking before 3.28 please :)


> The question I tried to raise (less concretely) was
> 	struct ike_proposals vs struct ike_proposals *
> not
> 	struct ike_proposals vs struct proposals
>
> Both are interesting question.

I dont think the number of include files used should really affect
this decision?

> More generally, we are constantly increasing the entropy of our code
> and I want us to push back at that.

Soon we will have draft-ietf-ikev1-ah-oldcrypto-diediedie :) Plan to
have first draft ready for IETF 104 :)

Some merging of stack specific things would be nice too, like having
reqid on PF_KEY would allow us to completely remove saref and friends,
and a bunch of difficult lookup connection/hostpair things.

I do appreciate it every time you kill complexity. Thanks!

Paul


More information about the Swan-dev mailing list