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>

'__builtin_strncpy' offset [275, 4095] from the object at
'direntry' is out of the bounds of referenced subobject 'd_name'
with type 'char[256]' at offset 19
Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10343)

(cherry picked from commit db5cf86535b305378308c58c52596994e1ece1e6)

Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NPaul Dale <paul.dale@oracle.com>
Reviewed-by: NMatthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7277)

(cherry picked from commit 46d085096c6ead624c61e4b8b301421301511e64)

When OPENSSL_DIR_read implemented by LPdir_unix.c gets a Unixy path,
it will return file names like you'd expect them on Unix.

However, if given a path with VMS syntax, such as "[.foo]", it returns
file names with generation numbers, such as "bar.txt;1", which makes
sense for VMS expectations, but can be surprising for OpenSSL.

Our solution is to simply shave off the generation number if
OPENSSL_DIR_read() expects there should be one, and make sure not to
return the same file name twice.  Note that VMS filesystems are case
insensitive, so the check for duplicate file names are done without
regard to character case.
Reviewed-by: NTim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5587)

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)

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>

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.
----------------------------

with HP-UX offering 14 for NAME_MAX?

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.