| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
ok jsing@
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This traded local copies of CTASSERT() to the one in crypto_internal.h.
This change was backed out due to SHA-512 breakage on STRICT_ALIGNMENT
architectures still using Fred Flintstone's gcc without asm sha512.
Original commit message:
Use crypto_internal.h's CTASSERT()
Now that this macro is available in a header, let's use that version
rather than copies in several .c files.
discussed with jsing
|
| | |
|
| |
|
|
|
|
|
| |
Now that this macro is available in a header, let's use that version
rather than copies in several .c files.
discussed with jsing
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The current crypto_lock_init() function is not called early enough, meaning
that locks are already in use before it gets called. Worse, locks could be
in use when they are then initialised. Furthermore, since functions like
CRYPTO_lock() are public API, these could be called directly bypassing
initialisation.
Avoid these issues by using static initialisers.
ok bcook@
|
|
|
This implements automatic thread support initialization in libcrypto.
This does not remove any functions from the ABI, but does turn them into
no-ops. Stub implementations of pthread_mutex_(init|lock|unlock) are
provided for ramdisks.
This does not implement the new OpenSSL 1.1 thread API internally,
keeping the original CRYTPO_lock / CRYPTO_add_lock functions for library
locking. For -portable, crypto_lock.c can be reimplemented with
OS-specific primitives as needed.
ok beck@, tb@, looks sane guenther@
|
