obliterate

[Andrei Alexandrescu]

On 11/12/13 5:10 PM, Vladimir Panteleev wrote:
> On Wednesday, 13 November 2013 at 00:33:17 UTC, Andrei Alexandrescu wrote:
>> For starters, I want to define a function that "obliterates" an
>> object, i.e. makes it almost surely unusable and not obeying its own
>> invariants. At the same time, that state should be entirely
>> reproducible and memory-safe.
>
> What's this for? When will it be used?

Safe allocators.

> How will it behave in release mode? No-op, or same as non-release?

A safe allocator would obliterate in release mode if it wants to stay safe.

>> Here's what I'm thinking. First, obliterate calls the destructor if
>> present and then writes the fields as follows:
>>
>> * unsigned integers: t.max / 2
>>
>> * signed integers: t.min / 2
>>
>> * characters: ?
>
> Why not 0xFF? (char.init, invalid UTF-8 code unit)
>
>> * Pointers and class references: size_t.max - 65_535, i.e. 64K below
>> the upper memory limit. On all systems I know it can be safely assumed
>> that that area will cause GPF when accessed.
>
> Make that value odd. That will also guarantee a GPF on systems where
> unaligned pointer access is forbidden.
>
>> * Arrays: some weird length (like 17), and also starting at size_t.max
>> minus the memory occupied by the array.
>
> I guess the non-zero length is for code which is going to check it?
> Because otherwise, leaving length as just 0 will, in debug mode, cause a
> range error. In release mode, array index access will not check the
> length anyway.

I'm thinking along the lines of - empty arrays are common in sane objects.

>> * floating point numbers: NaN, or some ridiculous value like F.max / 2?
>
> NaNs are viral, so there's that.

Cool.


Andrei