Re: An auto_ptr bug in readString

Doh!  I believe I've made the same mistake in some code that I've
written--recently written, too.  (I corrected one utility I wrote a while
ago at work today.)  I've gotten tripped up by the delete[] operator being
different from the delete operator, but I recall that the difference is that
the delete[] operator calls a destructor on each element--for which there is
no effect for type char.

I believe the modern-day "preferred" solution to this is to use
vector<char>, to ensure that resource acquisition is initialization.  I'm
pretty sure there's a section in Scott Meyers' "Effective STL" on this
technique (yes... it's Item 16):

auto_ptr<char> p(new char[n]); //bad!
char *realp = p.get();

should be, instead, this:

vector<char> v(n);
char *realp = &v[0];

unless n is zero, in which case &v[0] will kill you; if n can be zero, you
should check for v.empty() before proceeding.

This improves on the raw pointer handling that was suggested in the patch;
say that either the in.read() call or the string constructor for the return
value throw an exception.  Then the memory allocated to temp is never
deallocated.

Just a suggestion.

----- Original Message -----
From: "Bostjan Lah" <[email protected]>
To: <[email protected]>
Sent: Saturday, May 04, 2002 12:21 PM
Subject: An auto_ptr bug in readString


Hi.

First thanks for this excellent CGI library. I have been using it
extensively for the past several months.
I recently also started using it with a memory leak detection tool
Valgrind (http://developer.kde.org/~sewardj/) and it kept reporting
unmatched new[] with delete / free (instead of delete []). The problem
function is readString which uses auto_ptr for allocating a char array
of readSize size, i.e.:
auto_ptr<char> temp(new char[readSize]);
auto_ptrs and arrays apparently don't mix so I'm attaching a patch for
CgiUtils.cpp which uses a simple char *temp instead.

Regards,
Bostjan