| Age | Commit message (Collapse) | Author |
|---|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
Release: yes
|
|
Fixes #21123
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21127)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Release: yes
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/18069)
|
|
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/16918)
|
|
'__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: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10343)
|
|
[skip ci]
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7827)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/7277)
|
|
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: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5587)
|
|
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3716)
|
|
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3689)
|
|
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
|
Reviewed-by: Richard 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: Richard 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: Richard Levitte <levitte@openssl.org>
|
|
Reviewed-by: Tim 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.
|
