[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

_strdup and delete

(2b|!2b)==?

12/17/2008 12:57:00 PM

is it safe to deallocate memory allocated with _strdup?

I suspect that _strdup alocates memory using malloc/calloc behind the
scenes - what are the dangers of using delete to free _strdup allocated
memory?
9 Answers

Kai-Uwe Bux

12/17/2008 1:22:00 PM

0

(2b|!2b)==? wrote:

> is it safe to deallocate memory allocated with _strdup?
>
> I suspect that _strdup alocates memory using malloc/calloc behind the
> scenes - what are the dangers of using delete to free _strdup allocated
> memory?

The standard does not mention _strdup.

The same applies to strdup, which is neither defined in the C++ standard nor
in the referenced C standard. However, that seems to be POSIX. According to
the man page, it obtains memory via malloc(), and the memory can be
released via free(). I suggest, you find the documentation for _strdup. It
should say something about this issues.


Best

Kai-Uwe Bux

Andrey Tarasevich

12/17/2008 4:55:00 PM

0

(2b|!2b)==? wrote:
> is it safe to deallocate memory allocated with _strdup?

Well, the real question is whether you _should_ deallocate that memory,
i.e. whether you _own_ it once it is allocated. You have to read the
docs in order to find that out. '_strdup' is not a standard function.

> I suspect that _strdup alocates memory using malloc/calloc behind the
> scenes - what are the dangers of using delete to free _strdup allocated
> memory?

If the memory is allocated with 'malloc/calloc', then you simply cannot
deallocate if with 'delete', period. There's not much sense in
discussing the "dangers" of trying to do so.

--
Best regards,
Andrey Tarasevich

Jeff Schwab

12/17/2008 5:24:00 PM

0

Andrey Tarasevich wrote:

> If the memory is allocated with 'malloc/calloc', then you simply cannot
> deallocate if with 'delete', period. There's not much sense in
> discussing the "dangers" of trying to do so.

I'm not aware of any guarantee that deleting malloc'd memory will not
free the memory. In fact, this is exactly what happens on some
platforms. "Simply cannot" is overstating the case.

Jeff Schwab

12/17/2008 5:32:00 PM

0

(2b|!2b)==? wrote:
> is it safe to deallocate memory allocated with _strdup?

As Kai-Uwe pointed out, POSIX strdup uses malloc, and you're supposed to
free the returned memory. GNU provides an strdupa function that uses
memory in the local stack frame, and is freed when the current function
returns.

Why are you calling _strdup, rather than using std::strings?

> I suspect that _strdup alocates memory using malloc/calloc behind the
> scenes - what are the dangers of using delete to free _strdup allocated
> memory?

At best, your code will be non-portable. At worst, Bad Things can
happen (undefined behavior).

Rolf Magnus

12/17/2008 8:29:00 PM

0

Jeff Schwab wrote:

> Andrey Tarasevich wrote:
>
>> If the memory is allocated with 'malloc/calloc', then you simply cannot
>> deallocate if with 'delete', period. There's not much sense in
>> discussing the "dangers" of trying to do so.
>
> I'm not aware of any guarantee that deleting malloc'd memory will not
> free the memory.

There is no guarantee at all for a program that tries to do that. It's
undefined behavior.

> In fact, this is exactly what happens on some platforms. "Simply cannot"
> is overstating the case.

In the same sense as "you simply cannot dereference a null pointer".

ram

12/17/2008 9:39:00 PM

0

Jeff Schwab <jeff@schwabcenter.com> writes:
>I'm not aware of any guarantee that deleting malloc'd memory
>will not free the memory.

#include <cstdlib>
#include <cstdio>

void f()
{ void * x = ::std::malloc( 1 );
if( x )::std::printf( "%p", x ); }

I am not aware of any guarantee that the printf
call will not free the memory. Are you?

James Kanze

12/18/2008 9:36:00 AM

0

On Dec 17, 6:23 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> Andrey Tarasevich wrote:
> > If the memory is allocated with 'malloc/calloc', then you
> > simply cannot deallocate if with 'delete', period. There's
> > not much sense in discussing the "dangers" of trying to do
> > so.

> I'm not aware of any guarantee that deleting malloc'd memory
> will not free the memory. In fact, this is exactly what
> happens on some platforms. "Simply cannot" is overstating the
> case.

It's undefined behavior. In theory, an implementation could
define it, but they'd have to do so in a way that would work
with any user supplied global operator new/operator delete as
well. In practice, it's quite likely to cause problems as soon
as you replace the global new/delete operators (say with
debugging versions).

So "simply cannot" applies, just as it applies for using an
uninitialized variable, dereferencing a null pointer, using an
object after it has been freed, etc.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Jeff Schwab

12/18/2008 4:49:00 PM

0

James Kanze wrote:
> On Dec 17, 6:23 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>> Andrey Tarasevich wrote:
>>> If the memory is allocated with 'malloc/calloc', then you
>>> simply cannot deallocate if with 'delete', period. There's
>>> not much sense in discussing the "dangers" of trying to do
>>> so.
>
>> I'm not aware of any guarantee that deleting malloc'd memory
>> will not free the memory. In fact, this is exactly what
>> happens on some platforms. "Simply cannot" is overstating the
>> case.
>
> It's undefined behavior. In theory, an implementation could
> define it, but they'd have to do so in a way that would work
> with any user supplied global operator new/operator delete as
> well. In practice, it's quite likely to cause problems as soon
> as you replace the global new/delete operators (say with
> debugging versions).

With you so far...

> So "simply cannot" applies, just as it applies for using an
> uninitialized variable, dereferencing a null pointer, using an
> object after it has been freed, etc.

None of those things "simply cannot" be done. They're just likely to
cause problems (since they invoke UB). Saying you "simply cannot
deallocate" malloc'd memory with delete implies a guarantee that does
not exist. "You can't do this" is a very different statement from "you
don't do this."

A certain popular operating system used to warn you, when you deleted a
file, that the file would not be recoverable. A lot of individuals and
businesses took that as a guarantee, and were therefore justifiably
surprised when their "deleted" files were recovered by others, often to
devastating effect. Deleting malloc'd memory is certainly not
guaranteed to free the memory, but neither is that behavior prohibited
by the standard. The only blanket statement that can be made is that
it's UB.

AnonMail2005@gmail.com

12/18/2008 9:42:00 PM

0

On Dec 18, 2:59 pm, "(2b|!2b)==?" <void-s...@ursa-major.com> wrote:
> Jeff Schwab wrote:
> > (2b|!2b)==? wrote:
> >> is it safe to deallocate memory allocated with _strdup?
>
> > As Kai-Uwe pointed out, POSIX strdup uses malloc, and you're supposed to
> > free the returned memory.  GNU provides an strdupa function that uses
> > memory in the local stack frame, and is freed when the current function
> > returns.
>
> > Why are you calling _strdup, rather than using std::strings?
>
> >> I suspect that _strdup alocates memory using malloc/calloc behind the
> >> scenes - what are the dangers of using delete to free _strdup
> >> allocated memory?
>
> > At best, your code will be non-portable.  At worst, Bad Things can
> > happen (undefined behavior).
>
> I'm maintaining legacy code - which is rats nest of strdup, new, new[]
> and free/delete/delete[] being called inconsistently ... stuff of
> nightmares ...- Hide quoted text -
>
> - Show quoted text -

How many lines of code? And is the app a "batch" run (where it starts
and finishes) or does it stay alive (e.g. a server). If the number of
lines of code is not huge, and the app is a batch run, I would lean
towards replacing each strdup with a std::string or some other object
that cleans up it's resources in it's destructor. Of course you will
have to weigh this effort against how long the application will be
supported in the future. But if the app will be around for some time
it's better to clean it up now - you will sleep better.

The key is to write a good number of regression tests for the existing
app, and use the same tests to test your newly revised code.

HTH