--- Comment #44 from Steven Schveighoffer <> 2012-06-04 
10:45:33 PDT ---
(In reply to comment #7)
> In general response to this bug, I'm unsure how pointers should be treated by
> the optimizer.  My gut feeling is the compiler/optimizer should trust the code
> "knows what it's doing." and so should expect that the code implicitly knows
> how much data it can access after the pointer.

After thinking about this for a couple days (and watching the emails pour in
with differing opinions), here is what I think pure functions with pointers
should mean:

For @system or @trusted functions, the definition of what data the pointer has
access to is defined by the programmer, and not expressed in possible way to
the type system or the compiler.  In other words, if I have a pointer to
something, the actual data referenced includes any number of bytes before or
after the memory pointed at.  The scope of that data is defined by the
programmer of the function/type, and should be clearly documented to the user
of the function.

For @safe functions, the compiler should allow access only to the specific item
pointed to as defined by the pointed-at type, and nothing else (pointer math is
disallowed, pointer indexing is disallowed, and casting is disallowed).

For pure functions, no conservative assumptions should be made or acted upon
during optimizations that expect the function has access to global data.  In
other words, a @system pure function that accepts a pointer should rightly
assume that the function does *not* access global data, and that whatever data
the function accesses via its pointer was passed via its parameter as expected
by the caller.  If the function incorrectly accesses global data via its
pointer, then it results in undefined behavior.

These expectations and behaviors should be spelled out in the spec.

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to