| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This way all the EVP_MD accessors are in the order of the struct fields.
Well, arguably the EVP_MD_meth* should come first, but they are scheduled
to go meet the dodo.
|
| |
|
|
| |
This way the accessors are sorted the same way as the struct.
|
| |
|
|
|
|
|
| |
This way the file has EVP_Digest*, then EVP_MD_CTX new/free/clean,
then ctrl then the EVP_MD_CTX accessors, then the EVP_MD accessors
and finally the EVP_MD_meth stuff and the order of things starts
making a wee bit of sense.
|
| |
|
|
|
|
| |
This way new/free aka create/destroy are next to each other. reset/cleanup
are the same thing and init will join the club after some other fixing
because two APIs that do the exact same thing aren't enough.
|
| | |
|
| |
|
|
|
| |
These are ~200 lines of EVP_MD API that separated two parts of the file
dedicated to EVP_CIPHER thingies.
|
|
|
EVP_Digest{Init,Update,Final}() move from digest.c to evp_digest.c which
will become the home of all things related to EVP_MD{,_CTX} handling.
EVP_Cipher{Init,Update,Final}() move from evp_enc.c to evp_cipher.c which
will become the home of all things related to EVP_CIPHER{,_CTX} handling.
EVP_Encode{Init,Update,Final}() move from encode.c to evp_encode.c which
already is the home of EVP_ENCODE_CTX_{new,free}().
discussed with jsing
|
