Apart from public and internal header files, there is a third type called
local header files, which are located next to source files in the source
directory. Currently, they have different suffixes like

  '*_lcl.h', '*_local.h', or '*_int.h'

This commit changes the different suffixes to '*_local.h' uniformly.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)

Currently, there are two different directories which contain internal
header files of libcrypto which are meant to be shared internally:

While header files in 'include/internal' are intended to be shared
between libcrypto and libssl, the files in 'crypto/include/internal'
are intended to be shared inside libcrypto only.

To make things complicated, the include search path is set up in such
a way that the directive #include "internal/file.h" could refer to
a file in either of these two directoroes. This makes it necessary
in some cases to add a '_int.h' suffix to some files to resolve this
ambiguity:

  #include "internal/file.h"      # located in 'include/internal'
  #include "internal/file_int.h"  # located in 'crypto/include/internal'

This commit moves the private crypto headers from

  'crypto/include/internal'  to  'include/crypto'

As a result, the include directives become unambiguous

  #include "internal/file.h"       # located in 'include/internal'
  #include "crypto/file.h"         # located in 'include/crypto'

hence the superfluous '_int.h' suffixes can be stripped.

The files 'store_int.h' and 'store.h' need to be treated specially;
they are joined into a single file.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7089)

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Conceptually, this is a squashed version of:

    Revert "Address feedback"

    This reverts commit 75551e07.

and

    Revert "Add CRYPTO_thread_glock_new"

    This reverts commit ed6b2c79.

But there were some intervening commits that made neither revert apply
cleanly, so instead do it all as one shot.

The crypto global locks were an attempt to cope with the awkward
POSIX semantics for pthread_atfork(); its documentation (the "RATIONALE"
section) indicates that the expected usage is to have the prefork handler
lock all "global" locks, and the parent and child handlers release those
locks, to ensure that forking happens with a consistent (lock) state.
However, the set of functions available in the child process is limited
to async-signal-safe functions, and pthread_mutex_unlock() is not on
the list of async-signal-safe functions!  The only synchronization
primitives that are async-signal-safe are the semaphore primitives,
which are not really appropriate for general-purpose usage.

However, the state consistency problem that the global locks were
attempting to solve is not actually a serious problem, particularly for
OpenSSL.  That is, we can consider four cases of forking application
that might use OpenSSL:

(1) Single-threaded, does not call into OpenSSL in the child (e.g.,
the child calls exec() immediately)

For this class of process, no locking is needed at all, since there is
only ever a single thread of execution and the only reentrancy is due to
signal handlers (which are themselves limited to async-signal-safe
operation and should not be doing much work at all).

(2) Single-threaded, calls into OpenSSL after fork()

The application must ensure that it does not fork() with an unexpected
lock held (that is, one that would get unlocked in the parent but
accidentally remain locked in the child and cause deadlock).  Since
OpenSSL does not expose any of its internal locks to the application
and the application is single-threaded, the OpenSSL internal locks
will be unlocked for the fork(), and the state will be consistent.
(OpenSSL will need to reseed its PRNG in the child, but that is
an orthogonal issue.)  If the application makes use of locks from
libcrypto, proper handling for those locks is the responsibility of
the application, as for any other locking primitive that is available
for application programming.

(3) Multi-threaded, does not call into OpenSSL after fork()

As for (1), the OpenSSL state is only relevant in the parent, so
no particular fork()-related handling is needed.  The internal locks
are relevant, but there is no interaction with the child to consider.

(4) Multi-threaded, calls into OpenSSL after fork()

This is the case where the pthread_atfork() hooks to ensure that all
global locks are in a known state across fork() would come into play,
per the above discussion.  However, these "calls into OpenSSL after
fork()" are still subject to the restriction to async-signal-safe
functions.  Since OpenSSL uses all sorts of locking and libc functions
that are not on the list of safe functions (e.g., malloc()), this
case is not currently usable and is unlikely to ever be usable,
independently of the locking situation.  So, there is no need to
go through contortions to attempt to support this case in the one small
area of locking interaction with fork().

In light of the above analysis (thanks @davidben and @achernya), go
back to the simpler implementation that does not need to distinguish
"library-global" locks or to have complicated atfork handling for locks.
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5089)

Reviewed-by: NPaul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4294)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4217)

Breaks djgpp, masks a common kernel function name.
Thanks to Gisle Vanem for pointing this out.
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3776)

Various initialization functions modify this table, which can cause heap
corruption in the absence of external synchronization.

Some stats are modified from OPENSSL_LH_retrieve, where callers aren't
expecting to have to take out an exclusive lock. Switch to using atomic
operations for those stats.
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3525)

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

If lh_OBJ_NAME_insert() fails then the allocated |onp| value is leaked.

RT#2238
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Rename sk_xxx to OPENSSL_sk_xxx and _STACK to OPENSSL_STACK
Rename lh_xxx API to OPENSSL_LH_xxx and LHASH_NODE to OPENSSL_LH_NODE
Make lhash stuff opaque.
Use typedefs for function pointers; makes the code simpler.
Remove CHECKED_xxx macros.
Add documentation; remove old X509-oriented doc.
Add API-compat names for entire old API
Reviewed-by: NDr. Stephen Henson <steve@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

No code change
Reviewed-by: NKurt Roeckx <kurt@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

We are using strcmp() as the cmp_func, where in the EDK2 environment
strcmp actually ends up being the external AsciiStrCmp() function —
an EFI library function defined with the Microsoft ABI.

This means that we can't just assign function pointers to it, since
in GCC-hosted builds the ABI of any function *not* explicitly marked
EFIAPI is the native SysV ABI.

Arguably this stupidity ought to be resolved on the UEFI side, but in
the general case that would mean that we need to provide ABI-compatible
wrappers for *all* the "standard" functions, just in case they're used
like this.

And in fact we already have a workaround here for DEC C. So instead of
playing games with casting function pointers, it's nicer just to use a
simple function to wrap the strcmp() call. That cleans up the DEC C
workaround, *and* it works around the UEFI bogosity at the same time.
Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

Signed-off-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>

Make LHASH_OF use static inline functions.

Add new lh_get_down_load and lh_set_down_load functions and their
typesafe inline equivalents.

Make lh_error a function instead of a macro.
Reviewed-by: NRich Salz <rsalz@openssl.org>

Only two macros CRYPTO_MDEBUG and CRYPTO_MDEBUG_ABORT to control this.
If CRYPTO_MDEBUG is not set, #ifdef out the whole debug machinery.
        (Thanks to Jakob Bohm for the suggestion!)
Make the "change wrapper functions" be the only paradigm.
Wrote documentation!
Format the 'set func' functions so their paramlists are legible.
Format some multi-line comments.
Remove ability to get/set the "memory debug" functions at runtme.
Remove MemCheck_* and CRYPTO_malloc_debug_init macros.
Add CRYPTO_mem_debug(int flag) function.
Add test/memleaktest.
Rename CRYPTO_malloc_init to OPENSSL_malloc_init; remove needless calls.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Don't define stacks in C source files: it causes warnings
about unused functions in some compilers.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Applications wishing to include their own stacks now just need to include

DEFINE_STACK_OF(foo)

in a header file.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Continuing from previous commit ensure our style is consistent for malloc
return checks.
Reviewed-by: NKurt Roeckx <kurt@openssl.org>

After openssl_zalloc, cleanup more "set to 0/NULL" assignments.
Many are from github feedback.
Reviewed-by: NTim Hudson <tjh@openssl.org>

For a local variable:
        TYPE *p;
Allocations like this are "risky":
        p = OPENSSL_malloc(sizeof(TYPE));
if the type of p changes, and the malloc call isn't updated, you
could get memory corruption.  Instead do this:
        p = OPENSSL_malloc(sizeof(*p));
Also fixed a few memset() calls that I noticed while doing this.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Following ANSI C rules, remove the casts from calls to
OPENSSL_malloc and OPENSSL_realloc.
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NMatt Caswell <matt@openssl.org>

Miscellaneous unchecked malloc fixes. Also fixed some mem leaks on error
paths as I spotted them along the way.
Reviewed-by: NTim Hudson <tjh@openssl.org>

The mkstack.pl script now generates the entire safestack.h file.
It generates output that follows the coding style.
Also, removed all instances of the obsolete IMPLEMENT_STACK_OF
macro.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

Reviewed-by: NTim Hudson <tjh@openssl.org>

knock-on work than expected - they've been extracted into a patch
series that can be completed elsewhere, or in a different branch,
before merging back to HEAD.

failure and freeing up memory if a failure occurs.

PR:620

PR: 49

example) are declared with some extra linkage information.  This
generates a warning when using the function name as a value to a
regular function pointer with the "correct" definition of the
function.  Therefore, use a macro to cast the appropriate function on
VMS.

callbacks, and their prototypes were consistent as they were. These casts
need reversing.

Also, I personally find line breaks during parameter lists (ie a line
ending in a comma) easier to read at a glance than line breaks at the end
of a function call and before a dereference on the return value (ie a line
ending in a closed-bracket followed by a line starting with "->").