[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 970613: GDBM files in LDM V5.0.3

>To: address@hidden
>cc: address@hidden
From: address@hidden (Peter Neilley)
>Subject: GDBM files in LDM V5.0.3
>Keywords: 199706132130.PAA24122
>
> Version 5.0.3 of the LDM was modified to store a trailing NULL character
> to the end of the GDBM key when writing data to gdbm files.
> This is occurring in src/pqact/filel.c
> on the line:
>
> 1431:     key.dsize = (int) strlen(key.dptr) + 1; /* include the \0 */
>
> where the " + 1" is new to V5.0.3.

It's actually line 1473 in the currently checked in version.
Mitch may be behind on announcing changes. :-)

> This causes a problem for GDBM readers in that "keyed" gdbm
> searches that do not include the trailing NULL will fail.

I hadn't considered this problem when I made the change.

> Although gdbm readers can be modified to append a NULL to the key,
> a general solution that allows access to GDBM files created
> with earlier versions of the LDM is difficult since there is no way
> to know apriori whether or not the gdbm file being read was created
> with an LDM before or after v5.0.3.
> One could, I suppose, try reading the regular and null-terminated keys,
> but that's not very elegant or efficient.
>
> Anyway, I was wondering what the reasoning was for including the
> NULL to the GDBM keys,

The problem that the  \0 termination is attempting to solve is
as follows. There are some gdbm functions which return a "key":
gdbm_firstkey() and gdbm_nextkey(). If the key.dsize was not stored
as strlen(keystring) + 1, then the key.dptr you get back from these
functions is not a C string. One has to copy the key so obtained to
other storage and then terminate it prior to use with C library functions.

The utility program "testgdbm" does not make such a copy.
So it may dump core, as would the old program 'dbcat', when handed gdbm
files created with unterminated keys.

> and if LDM-developers might reconsider this modification.

One can make things work either way, by adopting the convention
that the keys are C strings, or by adopting the convention that
one should always copy out the key.dptr into a string.
The minimum change to our codebase (and the one which is consistant
with the author of gdbm-provided utility) is to do as we have done,
\0 terminating the key. EG, I considered the lack of the \0 ldmdb_put()
programming error.

Since you are the contact point for all the users of this ldm feature,
we can certainly back out of this. You need to understand than
if we do, one can't use testgdm as provided or the old ldm dbcat
utility on the files so produced. Further, if any program which
uses gdbm_firstkey(), gdbm_nextkey() to dump the database would
have to be carefully and unconventionally written.

-glenn