[RW] Rogue Wave standard library -- unbelievable bug

[Old Wolf]

The following code causes a deallocation of a random amount of
bytes, with the Rogue Wave STL supplied with Borland C++ 5.5.1 :

#include <vector>

int main()
{
std::vector<char> v, w(1);
v = w;
}

There is a bug in the vector:perator= code that uses the wrong
value when determining how much memory to deallocate when
deallocating the old contents of v.

I'm amazed that a company which provides STL implementations to
professional compiler vendors, can let this slip through their
QA system. I couldn't find any mention of it in their Knowledge
Base either (although it has a very hard to use search system),
and you can't enter the RW STL patches area of their website
without a login ID. There's no mention of it on Borland's site
either.

Does anyone know if later versions fixed this (eg. BCC 5.6.4),
or if there are any freely-available patches? Are there any
more howlers like this one that I haven't come across yet?

 

[sebor]

There might be. I don't know if Borland still maintains this old
library.

What is the date on the Rogue Wave copyright notice at the top of the
file? I suspect it must be at least 5 years old and, AFAIK, Borland
hasn't taken any of our updates in about that long (which doesn't mean
that the library has never been updated, just not with our code). Your
program does the right thing with our latest library as well as with
several older versions (I tried 2.0.3 from 1998 that comes with Compaq
C++, 2.1.1 with SunProm and 2.2.1 with HP aCC), so it seems that it's
time to upgrade.

 

[Old Wolf]

What is the date on the Rogue Wave copyright notice at the top of
the file? I suspect it must be at least 5 years old and, AFAIK,
Borland hasn't taken any of our updates in about that long
(which doesn't mean that the library has never been updated,
just not with our code).

(c) 1994-1999 Rogue Wave Software Inc.
I couldn't find a specific version number anywhere.

program does the right thing with our latest library as well as
with several older versions (I tried 2.0.3 from 1998 that comes
with Compaq C++, 2.1.1 with SunProm and 2.2.1 with HP aCC), so
it seems that it's time to upgrade.

Is it possible for me to upgrade the standard library without
upgrading the compiler? (free of charge?) There's only 1 later
version of Borland, and they have since dropped C++Builder, so
it's not a great economic decision to get it.

The actual code snippet in question was, from vector.cc:

if (x.size() > capacity())
{
__value_alloc_type va(__end_of_storage);
iterator tmp = va.allocate(x.end() - x.begin(),0);
#ifndef _RWSTD_NO_EXCEPTIONS
try {
__end_of_storage = uninitialized_copy(x.begin(), x.end(), tmp);
} catch(...) {
va.deallocate(tmp,x.end()-x.begin());
throw;
}
#else
__end_of_storage = uninitialized_copy(x.begin(), x.end(), tmp);
#endif // _RWSTD_NO_EXCEPTIONS
__destroy(__start, __finish);
va.deallocate(__start,__end_of_storage.data()-__start);
__start = tmp;
}

As you can see, the va.deallocate() at the end is calculating
the amount with the NEW version of __end_of_storage but the
old version of __start. I fixed it by remembering the length
to deallocate, before __end_of_storage gets reassigned.

 

[sebor]

I'm not familiar with the Borland support policy, you'd need to talk to
them. We don't have the Borland compiler on our current support matrix
so if you got the code from us you'd have to do some porting (and it
probably wouldn't be free, although I'd encourage you to call our sales
and ask

The version macro, _RWSTD_VER, should be #defined by #including any
library header. I'm not sure if that convention was in place in '99,
though.

The code and the problem you're describing sounds familiar but I'm
afraid I'm too busy right now to hunt down the change that fixed it.
Below is the definition of the assignment operator from our latest
released branch.

Hope it helps.

vector<_TypeT, _Allocator>&
vector<_TypeT, _Allocator>::
operator= (const vector &__rhs)
{
if (capacity () < __rhs.size ())
vector (__rhs).swap (*this);
else if (&__rhs != this)
assign (__rhs.begin (), __rhs.end ());

return *this;
}

 

[Old Wolf]

I'm not familiar with the Borland support policy, you'd need to
talk to them. We don't have the Borland compiler on our current
support matrix so if you got the code from us you'd have to do
some porting (and it probably wouldn't be free, although I'd
encourage you to call our sales and ask

The version macro, _RWSTD_VER, should be #defined by #including
any library header. I'm not sure if that convention was in place
in '99, though.

Oh yes -- it is 0x020101. Thanks for your answers anyway.
I'm doing my best to convince the upper echelons to switch
to a new compiler.. you know how it goes

Below is the definition of the assignment operator from our latest
released branch.

vector<_TypeT, _Allocator>&
vector<_TypeT, _Allocator>::
operator= (const vector &__rhs)
{
if (capacity () < __rhs.size ())
vector (__rhs).swap (*this);
else if (&__rhs != this)
assign (__rhs.begin (), __rhs.end ());

return *this;
}

Looks like there have been many improvements since 1999

 

[Pete Becker]

There's only 1 later
version of Borland, and they have since dropped C++Builder, so
it's not a great economic decision to get it.

Well, there's "dropped" and there's "dropped." They've dropped it as a
standalone product. C++ support will be integrated into the next release
of Delphi (if I understand correctly), and includes our library.