Update the crypto API glue to conform to most of the current coding

practices (except lack of tabs).  Use the helper functions k5alloc,
zapfree, and find_enctype to reduce code size.

git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@22839 dc483132-0cff-0310-8789-dd5450dbe970

1 files changed, 20 insertions, 14 deletions

diff --git a/src/lib/crypto/krb/cksumtypes.h b/src/lib/crypto/krb/cksumtypes.h
index c667e8a..05e7be6 100644
--- a/src/lib/crypto/krb/cksumtypes.h
+++ b/src/lib/crypto/krb/cksumtypes.h
@@ -34,23 +34,29 @@ struct krb5_cksumtypes {
     char *name;
     char *aliases[2];
     char *out_string;
-    /* if the hash is keyed, this is the etype it is keyed with.
-       Actually, it can be keyed by any etype which has the same
-       enc_provider as the specified etype.  DERIVE checksums can
-       be keyed with any valid etype. */
+    /*
+     * If the hash is keyed, this is the etype it is keyed with.
+     * Actually, it can be keyed by any etype which has the same
+     * enc_provider as the specified etype.  DERIVE checksums can
+     * be keyed with any valid etype.
+     */
     krb5_enctype keyed_etype;
-    /* I can't statically initialize a union, so I'm just going to use
-       two pointers here.  The keyhash is used if non-NULL.  If NULL,
-       then HMAC/hash with derived keys is used if the relevant flag
-       is set.  Otherwise, a non-keyed hash is computed.  This is all
-       kind of messy, but so is the krb5 api. */
+    /*
+     * I can't statically initialize a union, so I'm just going to use
+     * two pointers here.  The keyhash is used if non-NULL.  If NULL,
+     * then HMAC/hash with derived keys is used if the relevant flag
+     * is set.  Otherwise, a non-keyed hash is computed.  This is all
+     * kind of messy, but so is the krb5 api.
+     */
     const struct krb5_keyhash_provider *keyhash;
     const struct krb5_hash_provider *hash;
-    /* This just gets uglier and uglier.  In the key derivation case,
-       we produce an hmac.  To make the hmac code work, we can't hack
-       the output size indicated by the hash provider, but we may want
-       a truncated hmac.  If we want truncation, this is the number of
-       bytes we truncate to; it should be 0 otherwise.  */
+    /*
+     * This just gets uglier and uglier.  In the key derivation case,
+     * we produce an hmac.  To make the hmac code work, we can't hack
+     * the output size indicated by the hash provider, but we may want
+     * a truncated hmac.  If we want truncation, this is the number of
+     * bytes we truncate to; it should be 0 otherwise.
+     */
     unsigned int trunc_size;
 };