[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