[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: IDL management in idl.c

Howard Chu wrote:
alloca() is nice in general, but as I recall it's only reliable in GCC. If
we can rely on its behavior, then it would be good to use in the filterindex

We might need a HAVE_ALLOCA macro and fallback to (a) the old way or (b) use malloc().

as far as win32 it looks like alloca still throws an exception on failure. Although using MS specific C exceptions, that can be handled, but leaves the issue of performance loss due to the use of exceptions (?) and additional compiler checks.

I don't see any need to change the current behavior of the bdb_idl functions
since they don't nest recursively. At most, bdb_idl_insert_key() calls
bdb_idl_fetch_key() once to retrieve an existing key. So there are at most
BDB_IDL_DB_SIZE arrays on the stack. With the current sizes, this is never a
problem. If the objective here is to increase the sizes, that's another
Otherwise, the code in filterindex.c is the only place that presents the
danger of stack blowout, which is why I focused on that.

From our last conversion I assumed the otherwise.

From a security and memory optimization point of view, I'm concerned with OpenLDAP's use of the stack for large amounts dynamic data. I think ( overall ) it limits the amount of memory optimizations that can be done. This fear may very well be unfounded, but given the choice eg. ( maybe a configure macro ), I'd choose the to use the heap.

Is the use of the stack soley due to speed optimization? If so, how much are we gaining by staying on the stack?

On a sidenote, I see that in bdb_idl_delete_key we always assume that
deleting from a range is a no-op. Perhaps we should shrink the range if the
deleted item is either the lo or hi bound of the range? Hm, I guess there's
a bug here as well in the BDB_IDL_MULTI case, since it always uses a cursor
to delete the given item. If you delete the lo or hi bound of a range, the
range item will be "broken". Amazing the things you see after being away
from the code for a while.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support


http://linuxquestions.org/ - Ask linux questions, give linux help.
http://splint.org/ - Write safe C code. splint source-code analyzer.