Re: rw_match can address to memory after end of string buffer

[Martin Sebor]

Farid Zaripov wrote:

 > -----Original Message-----
 > From: Martin Sebor [EMAIL PROTECTED]
 > Sent: Monday, July 10, 2006 1:59 AM
 > To: stdcxx-dev@incubator.apache.org
 > Subject: Re: rw_match can address to memory after end of string buffer
 >
[...]
 >
 > >> Hmm, that does look like a subtle bug in rw_match(). Let
 > me look into
 > >> how best to fix it.
 >
 > The commit below should fix it. I'm not 100% happy with the
 > code and suspect there might still be some bugs lurking in
 > there but if they are there the current test doesn't reveal
 > them (even under Sun dbx with memory checking on) and none of
 > the string tests is showing any signs of problems either.
 > http://svn.apache.org/viewvc?rev=420363&view=rev

  The bug with addressing after the end of string still present.

  I updated the test 0.char.cpp to check this bug.

The problem with rw_match(a, b, 1) is that in order for the function
to determine how many elements from each array match it first needs
to check for the presence of the @ directive after reading the first
character from a. Consider the case when a = "[EMAIL PROTECTED]" and b = "b".
The value expected to be returned from rw_match(a, b, 1) is 1 but
to behave correctly rw_match() must read all 4 characters from a.
I.e., the third argument specifies the maximum number of characters
to compare after expansion. I suppose we could add a fourth argument
specifying the maximum number of elements before expansion. Would
that be helpful?

Btw., rw_match(char*, char*) treats both arrays the same while the
other overloads only treat the first one special. I suppose it might
make sense for all of them to behave the same. Comments?

  The diff file is attached.

I like the added functionality but we need to settle the question
above before deciding how to proceed. I'm also not crazy about the
increasingly heavy use of macros (IF_PREPARE_TEST). I would prefer
to see us replace them with a function (or template) instead. That
goes not only for the new macros (which are especially bloated)
but also for the existing ones (TEST).

Btw., I opened a bug against gcc for the bogus warning:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28656

Martin