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

Lennart Sorensen lsorense at csclub.uwaterloo.ca
Sun Apr 6 05:01:30 EEST 2014

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?

> 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

More information about the Swan-dev mailing list