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

Antony Antony antony at phenome.org
Thu Feb 14 06:56:03 UTC 2019


On Wed, Feb 13, 2019 at 11:33:01AM -0500, Andrew Cagney wrote:
> On Wed, 13 Feb 2019 at 04:41, Antony Antony <antony at phenome.org> wrote:
> > 2nd approach is move around definitions of struct. I imagine this is
> > Andrew's choice. Atleast in this case?
> 
> This isn't true.  The code evolution we're discussing here is truly
> unique.  These are the declarations in question lifted, verbatim, from
> "proposals.h": 

you are right. I was confused, probably a better naming and ideally less 
code churn would help:) You are using a mix of #1 and #3 without 
/* forward declaration */

You have good reasons and intention for these changes, however it is easy to 
feel those as over complications.

My spontaneous reaction to this series of churn is not to use struct name as 
variable names?

lets say I am following struct ike_proposals 

then I would notice
proposals.h:177 struct ike_proposals {
ikev1.h:10 struct ike_proposals;
ikev2_parent.c:638 struct ikev2_proposals *ike_proposals =

look inside 

proposals.h:177 
struct ke_proposals {
	        struct proposals *p;
}

ikev2_spdb_struct.c:230
struct ikev2_proposals {
	struct ikev2_proposal *proposal;

thanks for fixing the proposales code! I am happy with results in ikev2.

regards,
-antony


More information about the Swan-dev mailing list