On 23 May 2018 at 06:36, Steven Schveighoffer via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
> On 5/22/18 9:48 PM, Manu wrote:
>>
>> On 22 May 2018 at 06:44, Steven Schveighoffer via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 5/22/18 1:01 AM, Manu wrote:
>>>>
>>>> Ah! Dangling pointers... that might conservatively retain garbage.
>>>> That's a good reason.
>>>
>>>
>>>
>>> Well, I was thinking more along the lines of accessing memory that is no
>>> longer valid :) A destructor can, for instance, free C malloced memory.
>>
>>
>> The memory post-destruction is invalid... nobody will access it.
>> Accessing it should be undefined behaviour until such a time as the
>> memory is re-constructed with a new instance...
>>
>
> This particular sub-thread was about using destroy on something, not freeing
> the memory. The memory is not invalid.
>
> To clarify, I'm talking about something like this:
>
> struct S
> {
> int *foo;
> this(int x) { foo = cast(int*)malloc(int.sizeof); }
> ~this() { free(foo); }
> }
>
> auto s = S(1);
> destroy(s);
> *s.foo = 5; // oops
>
> If s.foo is reset to null, then you get a nice predictable segfault. If not,
> then you get memory corruption. Sure you can just say "undefined behavior",
> but I'd rather the defined behavior.
Yeah no... I'm happy with "accessing uninitialised memory is undefined
behaviour".
If you want defined behaviour; initialise the memory!
