| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
| |
string returns 0 with errno = ENOENT.
Reviewed-by: Andy Polyakov <appro@openssl.org>
|
| |
|
|
| |
submitted by Steven M. Schweda <sms@antinode.info>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
----------------------------
|
| |
|
|
|
| |
Don't have a constant that you're going to assign to, that's just
plain stupid (I was the stupidhead here...).
|
|
|
Now we have directory reading capabilities for VMS as well, and all
of it in a fairly general manner.
|
