This does not include the new hash routines since they will cause problems
when reading old hash files.
Since mpool(3) has been changed, provide a compatibility shim for older
binaries.
Obtained from: OpenBSD
open(). The previous logic only initializes the database when O_CREAT is
set, but as long as we can open and write the database, and the database
is empty, we should initialize it anyway.
Obtained from: OpenBSD
an invariant (actually, an ugly hack) to fail, and all Hell would break
loose.
When deleting a big key, the offset of an empty page should be bsize, not
bsize-1; otherwise an insertion into the empty page will cause the new key to
be elongated by 1 byte.
Make the packing more dense in a couple of cases.
- fix NULL dereference exposed on big bsize values;
Obtained from: NetBSD via OpenBSD
if the result is truncated.
db/hash/hash_page.c: use the same way to create temporary file as
bt_open.c; check snprintf() return value.
Obtained from: OpenBSD
all; before freeing memory, zero out them before we release it as free
heap. This will eliminate some potential information leak issue.
While there, remove the PURIFY option. There is a slight difference between
the new behavior and the old -DPURIFY behavior, with the latter initializes
memory with 0xff's. The difference between old and new approach does not
generate observable difference.
Obtained from: OpenBSD (partly).
(This is part of a larger changeset which is intended to reduce diff only,
thus some prototypes were left intact since they will be changed in the
future).
Verified with: md5(1)
caused by refering broken (uninitialized?) pointer which is retrieved
from __bt_new() (and from mpool_new()).
I don't know why this linp[0] is read before stored because this
should be controlled by .lower and .upper member of PAGE structure
which are correctly initialized.
But this workaround fixes the problem on my environment and this
module has #ifdef PURIFY option which initializes new and reused
memory from mpool by memset(p, 0xff, size) like as I did.
Please feel free to fix the real bug instead of my workaround.
mpool_open(3) - it is *not* really used for synchronization; in fact,
it is not used at all.
PR: 70929
Submitted by: Martin Kammerhofer <dada@sbox.tugraz.at>
MFC after: 3 days
to a buffer in the big key/data case, memmove() was used on pointers
to size_ts, but only sizeof(u_int32_t) bytes where copied. This broke
on big_endian architectures where sizeof(size_t) > sizeof(u_int32_t).
This bug broke portupgrade (by way of ruby_bdb1) on sparc64.
Approved by: re (rwatson)
Only warnings that could be fixed without changing the generated object
code and without restructuring the source code have been handled.
Reviewed by: /sbin/md5
