Tail pad optimization, cache friendlyness and C++ interrop

[Walter Bright via Digitalmars-d]

On 6/15/2014 2:48 AM, Timon Gehr wrote:
> On 06/15/2014 10:33 AM, Walter Bright wrote:
>>>
>>> What Timon is saying is that not all memory safe code is verifiably
>>> @safe.
>>
>> In D, they are defined to be the same thing,
>
> Since when?
>
> http://dlang.org/function
>
> "Function Safety
>
> Safe functions are functions that are _statically checked_ to exhibit _no
> possibility of undefined behavior_. Undefined behavior is often used as a vector
> for malicious attacks.
>
> Safe Functions
>
> Safe functions are marked with the @safe attribute.
>
> The following operations are not allowed in safe functions:"
>
> I.e. the documentation has two (conflicting) definitions and none of them is the
> one you claim there is.
>
>> so the statement makes no sense.
>
> Then please indicate how to fix the documentation. If you are going to claim the
> Humpty Dumpty privilege, I'll back off. Thanks.


I don't know why the documentation says that. D's @safe is about memory safety, 
not undefined behavior.

Note that the list of eschewed behaviors are possibly memory corrupting. Signed 
integer overflow, for example, is not listed.