Array bounds read at memcmp when purifying

[shahan.am]

HI..
I have a custom built String class. In that i used memcmp funtion
instead of strcmp since i have a track of length of the string.
Eg:
bool operator=(const char* pz)
{
return memcmp(buffer, pz, bufferlength + 1) == 0;
}

where 'buffer' is the actual data buffer i used to keep the string in
side my string class and bufferlength is the varible holds the length
of the string with out the null character at the end.

I compiled this in SUN solaris 5.10 with g++ compiler.

When purifying only sometimes it reports Array bound read.
Then i tried with this small program

#include <iostream>
using namespace std;

int main(int argc, const char** argv)
{
int ret = memcmp("XYZ", "ABCD_ABC_ABCDEF", 5);
cout << ret << endl;
return 0;
}

this also gives ABR warning, but when compiled with O3 option it does
NOT give the warning,..

what is the reason behind it ?

thank you all

 

[shahan.am]

Because "XYZ" is only 4 chars long?  And when you use O3, it probably
optimizes out all the checking code?

But i thought NULL character at the end of XYZ get compared with the
fourth character of the second string ('D') and terminated the
comparing. so even i gave the length as 5 shouldn't it terminate
before that ?

thanks

 

[red floyd]

But i thought NULL character at the end of XYZ get compared with the
fourth character of the second string ('D') and terminated the
comparing. so even i gave the length as 5 shouldn't it terminate
before that ?

That's strncmp, not memcmp. memcmp()

 

[James Kanze]

It's actually hard to say. What is certain is that you've
passed illegal arguments to memcmp, so the behavior of the
program is undefined. (Note that without <string.h>, it's not
even guaranteed to compile.) It's possible (although somehow I
doubt it) that the compiler uses a built-in version of memcmp
when optimizing is active, and then recognizes the constant
values, and doesn't actually ever call memcmp or do any
comparisons, where as the actual memcmp function may validate
its arguments, or be instrumented by Purify in some way to do
so.

If the checking code is Purify, it is inserted after
optimization, so there can be no question of the checking code
being optimized out. But optimization can lead to different
code being generated. (Although this wasn't the case when I
tried it on my Sparc, with g++ 4.1.0.)

But i thought NULL character at the end of XYZ get compared
with the fourth character of the second string ('D') and
terminated the comparing. so even i gave the length as 5
shouldn't it terminate before that ?

There's no requirement concerning this in the C standard. *You*
are required to provide pointers to "objects" which are greater
than or equal to n in size.

More than one implementation of memcmp that I've seen actually
compares words (4 or 8 byte blocks, depending on the hardware),
and only shifts to byte comparison once it's found an
inequality. Such an implementation *will* cause Purify to
complain, even if in cases where you pass legal parameters to
memcmp (e.g. memcmp( "A", "B", 1 )). Such an implementation is
legal if (and only if) the fact that one byte is mapped means
that all bytes of the word must be mapped---the case for all
hardware I know. And there's no real solution with regards to
Purify, except to replace memcmp with a "naïve" implementation
which does access byte by byte, never accessing more than n
bytes. (You could also filter out the error from Purify, but
this would mean missing real errors as well.)