| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Buy a vowel at the same time, since we're no longer limited to 8.3 file
names.
Discussed with tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_local.h, reserving the name *_internal.h for our own code.
Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h.
constant_time_locl.h is moved to constant_time.h since it's special.
Adjust all .c files in libcrypto, libssl and regress.
The diff is mechanical with the exception of tls13_quic.c, where
#include <ssl_locl.h> was fixed manually.
discussed with jsing,
no objection bcook
|
| |
|
|
| |
ok tb@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
meaningful constants in a private header file, so that reviewers can actually
get a chance to figure out what the code is attempting to do without knowing
all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned
64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will
now always use OPENSSL_cpu_caps() and check for the proper bits in the
whole 64-bit word it returns.
i386 tests and ok jsing@
|
| |
|
|
| |
ok deraadt@
|
| |
|
|
| |
ok deraadt@
|
| |
|
|
| |
Started by diff from Mical Mazurek.
|
| |
|
|
|
| |
more friendly to systems where the underscore flavours may be defined as empty.
Found the hard way be bcook@; joint brainstrom with bcook beck and guenther
|
| |
|
|
|
| |
these systems (vax being 30% faster!). (surprisingly, the prime candidate for
SMALL_REGISTER_BANK, SuperH, runs actually slower in that case)
|
| | |
|
| |
|
|
| |
Forgotten during yesterday's STRICT_ALIGNMENT cleanup commit.
|
| |
|
|
|
|
|
|
| |
Also check for _LP64 rather than __arch64__ (the former being more reliable
than __LP64__ or __arch64__) to tell 64-bit int platforms apart from 32-bit
int platforms.
Loosely based upon a diff from Martijn van Duren on tech@
|
| |
|
|
|
|
|
| |
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'
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before someone suggests the OpenSSL people are junkies, here is what they
mention about this:
/* Most will argue that x86_64 is always little-endian. Well,
* yes, but then we have stratus.com who has modified gcc to
* "emulate" big-endian on x86. Is there evidence that they
* [or somebody else] won't do same for x86_64? Naturally no.
* And this line is waiting ready for that brave soul:-) */
So, yes, they are on drugs. But they are not alone, the stratus.com people are,
too.
|
| | |
|
| |
|
