Hi,

In asserterror.d, a string buffer is mallocated, and it is never freed. The comments in the code say:

* We'll never free the malloc'd memory, but that doesn't matter, * as we're aborting anyway.

In truth, assert doesn't "abort." Rather, it throws an exception, which can be caught. In turn, this means means that program execution could perfectly well continue despite a failed assertion. Therefore, in such a case, the unfreed memory is leaked. Right?

Cheers,
--AJG.

On Wed, 17 Aug 2005 20:55:07 -0400, AJG <AJG_member@pathlink.com> wrote:

> Hi,
>
> In asserterror.d, a string buffer is mallocated, and it is never freed. The
> comments in the code say:
>
> * We'll never free the malloc'd memory, but that doesn't matter,
> * as we're aborting anyway.
>
> In truth, assert doesn't "abort." Rather, it throws an exception, which can be
> caught. In turn, this means means that program execution could perfectly well
> continue despite a failed assertion. Therefore, in such a case, the unfreed
> memory is leaked. Right?

Yes. I was going to complain about this when it was added but forgot to.

"AJG" <AJG_member@pathlink.com> wrote in message news:de0m9b$np6$1@digitaldaemon.com...
> Hi,
>
> In asserterror.d, a string buffer is mallocated, and it is never freed.
The
> comments in the code say:
>
> * We'll never free the malloc'd memory, but that doesn't matter, * as we're aborting anyway.
>
> In truth, assert doesn't "abort." Rather, it throws an exception, which
can be
> caught. In turn, this means means that program execution could perfectly
well
> continue despite a failed assertion. Therefore, in such a case, the
unfreed
> memory is leaked. Right?

Assert is expected to abort the program, not attempt to continue. The only reason it can be caught is so that some necessary shut down code can be executed.

In article <deqm8e$254o$3@digitaldaemon.com>, Walter says...

> "AJG" <AJG_member@pathlink.com> wrote in message news:de0m9b$np6$1@digitaldaemon.com...
<snip>
>> In truth, assert doesn't "abort." Rather, it throws an exception, which can be caught.  In turn, this means means that program execution could perfectly well continue despite a failed assertion.  Therefore, in such a case, the unfreed memory is leaked.  Right?
> 
> Assert is expected to abort the program, not attempt to continue.

That's what I thought.  However, I just realised another issue.  When contract inheritance is finally implemented,  then under the implementation logic I had suggested, there'll be a memory leak as a class's own in contract first generates an AssertError, which is then caught in order to try the inherited contract.

> The only reason it can be caught is so that some necessary shut down code can be executed.

Isn't that what finally is for?

Stewart.

AJG wrote:
> Hi,
> 
> In asserterror.d, a string buffer is mallocated, and it is never freed. The
> comments in the code say:
> 
> * We'll never free the malloc'd memory, but that doesn't matter,
> * as we're aborting anyway.
> 
> In truth, assert doesn't "abort." Rather, it throws an exception, which can be
> caught. In turn, this means means that program execution could perfectly well
> continue despite a failed assertion. Therefore, in such a case, the unfreed
> memory is leaked. Right?

Just thinking about it, the AssertError itself is created on the heap. So how is the exception message different?

And what's wrong with using the destructor to free the memory?  This would solve the problem in the odd cases where we're not aborting anyway, at virtually no cost to existing programs.  Just add to AssertError

    ~this() {
        std.c.stdlib.free(msg.ptr);
    }

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB@ P+ L E@ W++@ N+++ o K- w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.