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
