2. Pull up the actual minor processing code into the switch that
parses it.
3. atoi is actually simpler than strtonum in this case, but check the
input beforehand so we don't get unexpected results.
4. Slightly more consistent style between various parse and check and
increment operations on salt.
ok deraadt
we always junk small chunks now, and the first part of pages,
but only after free. J still does the old thing. j disables everything.
Consider experimental as we evaluate performance in the real world.
ok otto
but rather figure out the endianness from <machine/endian.h> automagically;
help from guenther@
ok jca@ guenther@ beck@ and the rest of the `Buena SSL rampage club'
are still some 3rd-party code using it, and fixing them is not trivial.
As an excuse gift, the memory leaks on failure in resurrected a_set.c have
been fixed.
supposedly smart compilers from optimizing memory cleanups away. Understood.
Ok, in case of an hypothetically super smart compiler, OPENSSL_cleanse() had
to be convoluted enough for the compiler not to recognize that this was
actually bzero() in disguise. Understood.
But then why there had been optimized assembler versions of OPENSSL_cleanse()
is beyond me. Did someone not trust the C obfuscation?
of des_old.h routines, acting as wrappers about the OpenSSL UI API.
Nothing should use these functions directly.
Riding the recent libcrypto major bump (in a `des' car).
are not please fix your operating system. Replace mem.c with an API-compatible
wrapper that just calls the system functions and does not allow a one word
modification of a variable in a running shared library to turn on memory
debug functions that expose things that should not be seen.
ok tedu@
The man page says "Compatibility des_ functions are provided for a short
while" and indeed even the original commit message says "The compatibility
functions will be removed in some future release, at the latest in
version 1.0." So here we are, a short while later.
Now I've only been an OpenBSD developer for 11 years, one year less than
this header has existed, but in that brief time, I've learned a thing or
two about deleting obsolete code. It doesn't delete itself. And worse,
people will continue using it until you force them onto a better path.
obsolete (and mostly internal) routines to be compiled out.
We don't expect any reasonable software to stick to these interfaces, so better
clean up the view and unifdef -DNO_ASN1_OLD.
The astute reader will notice the existence of NO_OLD_ASN1 which serves a
similar purpose, but is more entangled. Its time will come, soon.
tedu