[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