New commits:
commit da0ec658e4f0d2cead8e0fcc02a65aa3b525ffc6
Author: D. Hugh Redelmeier <[email protected]>
Date: Mon Jul 20 01:50:48 2015 -0400
pluto: get rid of hmac_pads
- the padding buffer is better allocated as an auto
+ one cannot accidentally fail to free an auto so one
doesn't even need to think about it.
+ a heap allocation inside a function without a suggestive name
(hmac_pads) may not make clear the obligation of the caller to
free the buffer
+ auto allocation is cheaper and creates less noise in heap
debugging.
- the one call that could not be replaced by code with an auto
allocation was not, in fact, hmac-related. It was padding
shortfall in a DH result. The replacement code is expected
to allocate heap memory once in 256^10 times (i.e. never).
It also frees it, but statistically the testing for freeing
will be MUCH more expensive than not bothering.
- tidy: I played with nearby code, exploiting C's mixing of
declarations and statements to make more declarations initializing.
_______________________________________________
Swan-commit mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-commit
