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

[Andrew Cagney]

On Wed, 13 Feb 2019 at 12:05, D. Hugh Redelmeier <hugh at mimosa.com> wrote:

> | However, pluto does still use the declarations - they provide a way to
> | strongly differentiate between an IKE and CHILD proposal.  But that is
> | something local to pluto and connections.h, hence my note above
> | pointing out that it should be moved as a *cleanup*.


> (I know you know this.)
>
> The (generic) trouble is that C only allows pointer-to-struct fields
> to be opaque, not struct fields.  The compiler needs to know the size
> of the field; all possible struct pointers are the same size, but not
> all possible structs.

Tehnical nit, this is allowed:
   struct klass;
   extern struct klass object;
   &object

> On the other hand, memory management is sometimes more onerous
> pointers-to-structs.  Sub-structs are automatically included in
> structs.
>
> Making a wise trade-off between these issues is part of the job of a C
> programmer.
>
> | But "XXX: useful?"?  Well, when rewriting the parser I did consider
> | dumping those two declarations and instead just using 'struct
> | proposals *' in "connections.h".  I decided against it.  It seemed to
> | me that the stronger type helped with readability vis:
> |    ikev1_quick_pfs(const struct child_proposals proposals)
>
> The question I tried to raise (less concretely) was
>         struct ike_proposals vs struct ike_proposals *
> not
>         struct ike_proposals vs struct proposals

These were the options I considered:

    struct ike_proposals {
      struct proposals *p;
    }
    struct ike_proposals ike_proposals;

   struct ike_proposals {
      struct proposal p;
  }
   struct ike_proposals * ike_proposals;

   struct ike_proposals {
      struct proposal *p;
  }
   struct ike_proposals *ike_proposals;

The first lets me safely write:

    proposals_delref(&c->ike_proposals.p);  // kills .p

good luck cleanly writing that using either #2 or #3; and #3 just
generates needless indirection.

I guess I should push my change.  It, with certain irony, tweaks some
functions so they pass around:
    const struct ike_proposals *
et.al.

> Both are interesting question.
>
> But I was just hoping that we could make the type opaque to the code
> that has no Need to Know.  I admit that the cost might be too high.
>
> More generally, we are constantly increasing the entropy of our code
> and I want us to push back at that.
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev