Commit graph

12 commits

Author SHA1 Message Date
Richard Levitte
a5829ae282 Adjust LPdir_unix.c on VMS for OpenSSL expectations
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)
2018-03-12 23:01:02 +01:00
Rich Salz
8d1598b0ce Fix typo (note by oneton@users.github)
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3716)
2017-06-20 08:15:00 -04:00
Rich Salz
0c3d0d4a01 Standardize Levitte's dual-license
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3689)
2017-06-15 14:16:16 -04:00
Richard Levitte
28e90f69fb Remove the silly CVS markers from LPdir_*.c
Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-07-16 07:58:23 +02:00
Rich Salz
2039c421b0 Copyright consolidation 08/10
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-05-17 14:51:34 -04:00
Rich Salz
16f8d4ebf0 memset, memcpy, sizeof consistency fixes
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>
2015-05-05 22:18:59 -04:00
Rich Salz
b4faea50c3 Use safer sizeof variant in malloc
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>
2015-05-04 15:00:13 -04:00
Matt Caswell
0f113f3ee4 Run util/openssl-format-source -v -c .
Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-01-22 09:20:09 +00:00
Richard Levitte
bb09fd2bb6 Import changed files from LPlib. The changes are logged as follows
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.
----------------------------
2004-09-23 22:11:39 +00:00
Andy Polyakov
f1bdf1d518 #include <limits.h> is required at least on HP-UX and IRIX. And what's
with HP-UX offering 14 for NAME_MAX?
2004-07-22 10:53:26 +00:00
Richard Levitte
210a4f78ae Imported from LPlib, making sure the entry name (at least on Unix) is
NUL-teminated at all times, and that we don't make unneeded calls to
free().
2004-07-19 16:36:28 +00:00
Richard Levitte
a2400fcab8 Copy a few files from LPlib (a new project of mine), add a wrapper.
Now we have directory reading capabilities for VMS as well, and all
of it in a fairly general manner.
2004-07-10 13:16:02 +00:00