RE: search_candidates on win32

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Kervin Pierre [mailto:kpierre@fit.edu]

> Howard Chu wrote:
> > We need a better solution here, since an arbitrarily complex
> search filter
> > will be able to trash the server,

> oh.  that's not good.  I thought the needed stack space was 'large' but
> 'fixed'.

No, the stack requirement is determined by the depth of nested <and/or>
clauses in the search filter. If you string enough of them together, you
will eat up all of the stack. This presents an easy denial-of-service
attack.

> > Unfortunately it feels like we're going to have to resort to
> using some form
> > of malloc here, which is going to cost some performance in the filter
> > evaluation, but it seems like the only safe approach.

> That is my ( uninformed ) opinion as well :).  With a reasonable attempt
> at memory management, I do not believe the performance hit would be much
> at all.

Yes. We can walk the filter tree once beforehand to count its depth, and do
a single malloc for that many IDLs all at once. Then advance along the
memory
as we descend into each filter evaluation. Also if the malloc fails, we know
immediately that we can't handle the filter, so there's no surprise failures
later on.

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