[Swan-dev] [Swan-commit] Changes to ref refs/heads/master

[David McCullough]

Lennart Sorensen wrote the following:
> On Sat, Apr 05, 2014 at 08:29:59PM -0400, D. Hugh Redelmeier wrote:
> > | From: Lennart Sorensen <lsorense at csclub.uwaterloo.ca>
> > 
> > | How is ty an improvement over type?
> > 
> > Long story short, it's more grepable.  "type" isn't unique.
> 
> grepping for ty still matches type.
> 
> I do hate meaningless variable names.  It makes it much harder for people
> not familiar with the code to make sense of it.
> 
> > Normally, if this mattered, we'd use a prefix.  But no prefix came to
> > mind.  cert.cert_type looks silly.
> 
> And ty doesn't?
> 
> And the type is named ike_cert_type, so how is calling it cert_type silly?

I would have to agree, cert_type, ctype, type, almost anything looks and feels
better than "ty" in my opinion ;-)

Cheers,
Davidm


> > Worse: it isn't clear what this field should be.  It isn't currently
> > really a type.  It's a discriminant for the union.
> > 
> >     typedef struct {
> > 	    enum ike_cert_type ty;
> > 	    union {
> > 		    /* some day we may support more */
> > 		    x509cert_t *x509;       /* CERT_X509_SIGNATURE */
> > 	    } u;
> >     } cert_t;
> > 
> > The only values for ty are CERT_NONE and CERT_X509_SIGNATURE (other
> > values of enum ike_cert_type are not used here).
> > 
> > This data structure could be simplified:
> > 
> >     typedef x509cert_t *cert_t
> > 
> > with NULL standing for the CERT_NONE case.
> > 
> > But there is some thought that this might get elaborated.  If I knew
> > how, a better representation would suggest itself.
> > 
> > For example, if we add another public-key cryptosystem, then the
> > discriminant would perhaps be "which cryptosystem".
> 
> Oh dear.
> 
> -- 
> Len Sorensen
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev

-- 
David McCullough,  ucdevel at gmail.com,   Ph: 0410 560 763