On Mon, 19 May 2014 18:46:22 -0400, Dicebot <pub...@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 <pub...@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
