Memory allocation purity

[Steven Schveighoffer via Digitalmars-d]

On Mon, 19 May 2014 18:46:22 -0400, Dicebot <public at dicebot.lv> wrote:

> On Monday, 19 May 2014 at 20:51:22 UTC, Steven Schveighoffer wrote:
>> On Mon, 19 May 2014 16:23:34 -0400, Dicebot <public at dicebot.lv> wrote:

>>> Oh, and are probably eager to show me links to specs which indicate  
>>> what part of my snippet breaks the type system? Is it allocation that  
>>> is forbidden in reasonable code? Or object identity?
>>
>> None is forbidden, and the combination above is a BUG. Bugs happen,  
>> compilers actually compile them. pure != bug-free.
>
> No it is not. It is semantically valid code which does exactly what it  
> was expected to do. Unless compiler optimization happens which will  
> actually introduce a bug silently. It is optimization that is broken,  
> not code itself.

Again, the bug is to break if a function that allocates an immutable  
object for some reason re-uses the immutable object (perfectly legitimate  
optimization, whether done by the compiler or intentionally).

I still have not seen the code that somehow can't handle this.

> And this is not some sort of imaginary code. `alloc` implementation may  
> be located in some other static library and not available to compiler.  
> It is likely to be not a plain `alloc` in real code but some utility  
> function that creates and returns object internally.

alloc isn't the problem. oops is incorrectly implemented to depend on  
implementation details of the allocator.

>>> Please stop this "write proper code" absurdism. This code is safe,  
>>> doesn't use casts or pointer forging or any other dirty low level  
>>> tricks. If compiler can't reject it as invalid and goes into funny  
>>> mode instead, compiler is fucked. There can be no excuse for it.
>>
>> The code above relies on implementation details of the allocator to do  
>> it's work. It's invalid to do so.
>
> Wrong again. It does not rely upon anything. It simply checks if two  
> objects returned by two functions calls are identical. With zero  
> assumptions about it.

Then why is oops returning true a failure case?

>> Please show me the code that goes into "funny land" because of an  
>> incorrect result of oops.
>
> What the hell are you speaking about? Getting two different results for  
> a function depending on -O flag is not weird enough for you?

It's not unheard of. When you violate language assumptions, it happens.  
I've seen code that breaks when -O is passed, vs. when it's not.

> - Hey, this program produces a wrong output!
> - But it doesn't wipe your system. You will be fine.

This is a superficial reading of my statement ;)

>
> At this point it is hard to believe you are serious and not trolling.

Yeah, it was kind of trolling, but I keep asking questions and have been  
given the same irrelevant answers. Sorry.

-Steve