incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: rw_match can address to memory after end of string buffer
Date Tue, 08 Aug 2006 19:10:18 GMT
Farid Zaripov wrote:
>  > -----Original Message-----
>  > From: Martin Sebor [mailto:sebor@roguewave.com]
>  > 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 = "a@0b" 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

Mime
View raw message