On Apr 19, 1:02 am, Carlos Moreno <cm_n...@[EMAIL PROTECTED]
> wrote:
> I guess my question about the UB was not specific enough;
> I mean, yes, allocating with new [] and releasing with
> delete *is* UB... My question was (or should have been):
> *in practical terms*, does this undefined behaviour goes
> all the way down to the memory allocation algorithms used
> by the compiler or the runtime memory-management system?
Yes, it might.
For example, U.B. gives the implementation freedom to do any run-time
checks. One of those could be to insert a flag somewhere in allocated
blocks to indicate array/non-array form of new used to allocate, and
then check it in delete, and assert(false) or throw if it doesn't
match. In fact, even if implementation doesn't do it out of the box, I
could very well overload global operator new/delete in my program for
the same purpose, and I am justified to expect any libraries I use to
handle this correctly:
void* operator new (std::size_t size)
{
char* result = static_cast<char*>(std::malloc(size + 1)) + 1;
result[-1] = 0;
return result;
}
void* operator new[] (std::size_t size)
{
char* result = static_cast<char*>(std::malloc(size + 1)) + 1;
result[-1] = 1;
return result;
}
void operator delete (void* p)
{
char* block = static_cast<char*>(p);
assert(block[-1] == 0);
std::free(block - 1);
}
void operator delete[] (void* p)
{
char* block = static_cast<char*>(p);
assert(block[-1] == 1);
std::free(block - 1);
}
I've actually seen one similar case of "well, but it's not really
U.B., 'cause I'm not doing anything wrong, so it must be okay!" in
real life: a person used &v[0] on vector without checking for empty()
first (and it could be empty there), passing the resulting pointer and
size() elsewhere. His reasoning was that if size()==0, he did not
dereference the pointer afterward, so whatever &v[0] produced in this
case, it would be okay. It worked fine, too, until we migrated to
Visual C++ 2005, which has a lot of checks in STL containers enabled
by default in debug builds; and then we've got assertion failures all
over our code because of that.
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
