Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: I5269be7d8e6c8ac399d86d9b48bfbd5cfabe0d19

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Signed-off-by: NHJ <huangjun42@huawei.com>

Description:openssl 1.1.1d used bu libhapverify
Team:OTHERS
Feature or Bugfix:Feature
Binary Source:Yes, it is
PrivateCode(Yes/No):No

Change-Id: I8968f9c0f146b587da17a3e603bd04fb7b4c505b
Reviewed-on: http://mgit-tm.rnd.huawei.com/7842784Tested-by: Npublic jenkins <public_jenkins@notesmail.huawei.com>
Reviewed-by: Nhouyuezhou 00386575 <hou@huawei.com>
Reviewed-by: Nlinyibin 00246405 <linyibin@huawei.com>
Reviewed-by: Nweiping 00548480 <ping.wei@huawei.com>

Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3716)

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

Mingw builds on Travis were failing because INT_MAX was undeclared.
Reviewed-by: NRich Salz <rsalz@openssl.org>

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

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

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

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

Just as with the OPENSSL_malloc calls, consistently use sizeof(*ptr)
for memset and memcpy.  Remove needless casts for those functions.
For memset, replace alternative forms of zero with 0.
Reviewed-by: NRichard Levitte <levitte@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>

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

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

string returns 0 with errno = ENOENT.
Reviewed-by: NAndy Polyakov <appro@openssl.org>

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

for LPdir_unix.c in LPlib.  For the other files, only the last log
entry applies.

----------------------------
revision 1.11
date: 2004/09/23 22:07:22;  author: _cvs_levitte;  state: Exp;  lines: +20 -6
Define my own macro LP_ENTRY_SIZE to express the size of my own
buffering of directory entries, and make it depend on whichever comes
first of PATH_MAX and NAME_MAX.  As a fallback, make sure it's set to
255 if neither PATH_MAX or NAME_MAX were defined.  Also, if the size
given from PATH_MAX or NAME_MAX is less than 255, force LP_ENTRY_SIZE
to be 255.

It makes no harm whatsoever if LP_ENTRY_SIZE is larger than the
maximum local path name limit.  It does make a lot of harm if
LP_ENTRY_SIZE is smaller.  255 seemed like a fairly acceptable default
when nothing else is available.
----------------------------
revision 1.10
date: 2004/08/26 13:36:05;  author: _cvs_levitte;  state: Exp;  lines: +13 -13
License correction.  I am not REGENTS, just a COPYRIGHT HOLDER.
----------------------------

because "wrong" casts will either be optimized away or never performed.

Apparently, the length *including* the NUL byte should be used.

Contributed by Andy Polyakov <appro@fy.chalmers.se>

Make a nicer comment, as we don't really know for sure that it's
really needed, and just want to play on the safe side.

Suggest by Andy Polyakov <appro@fy.chalmers.se>

Some code beautification.

Change the macro CP_THREAD_ACP to CP_ACP, because the latter is more
widely defined.

Add a conditional macro definition in case FindFirstFile and
FindNextFile aren't properly defined (might happen on WinCE).

Suggested by Andy Polyakov <appro@fy.chalmers.se>

Windows changes that detects if multibyte characters are available and
deals with them properly.

Contributed by Andy Polyakov <appro@fy.chalmers.se>

NUL-teminated at all times, and that we don't make unneeded calls to
free().

Now we have directory reading capabilities for VMS as well, and all
of it in a fairly general manner.