On 12/14/2013 08:30 PM, Walter Bright wrote:
> On 12/14/2013 9:19 AM, Timon Gehr wrote:
>> On 12/11/2013 12:46 AM, Walter Bright wrote:
>>> On 12/10/2013 3:04 PM, Timon Gehr wrote:
>>>> Malloc is part of the language runtime. Everything needed is known
>>>> about it, in
>>>> particular that it is pure (in the D sense). Also, the source code of
>>>> malloc
>>>> will not be standard C code.
>>>
>>> All right, so write your own storage allocator. How are you going to
>>> tell the C compiler that it's pure?
>>
>> How about the D compiler?
>
> You can cast the result to const/immutable, which is why the casting is
> possible. It tells the compiler things that cannot be deduced.

I cannot cast data from my own storage allocator to immutable because the behaviour will be undefined.

http://dlang.org/const3.html

Is this a documentation bug? What should be the actual rules?

On 12/14/2013 4:36 PM, Timon Gehr wrote:
> I cannot cast data from my own storage allocator to immutable because the
> behaviour will be undefined.
>
> http://dlang.org/const3.html
>
> Is this a documentation bug? What should be the actual rules?

It means it's up to you to ensure it is correct.

On Sunday, 15 December 2013 at 00:36:31 UTC, Timon Gehr wrote:
> I cannot cast data from my own storage allocator to immutable because the behaviour will be undefined.
>
> http://dlang.org/const3.html
>
> Is this a documentation bug? What should be the actual rules?

Casting to immutable is defined, it is modifying the data which is not. That is to say, by casting to immutable the compiler cannot guarantee no mutation will occur. I assume you're confusion comes from:

    char[] s = ...;
    immutable(char)[] p = cast(immutable)s;     // undefined behavior
    immutable(char)[] p = cast(immutable)s.dup; // ok, unique reference

The docs should probably be cleaned up, but it isn't exactly incorrect, since a mutable reference exists the compiler can't really define what behavior will occur if the program is run because it can't guarantee what behavior exists.

On Dec 14, 2013 10:51 PM, "Walter Bright" <newshound2@digitalmars.com> wrote:
>
> On 12/14/2013 11:46 AM, Iain Buclaw wrote:
>>
>> I honestly don't know how one would be able to make AsmStatement work for non-x86 architectures.  At least this is not possible in GDC unless you want to resort to doing things in a way that are shamed upon (like checking the definition of a particular TARGET macro :)
>
>
> I have no idea why it would be hard for non-x86?
>

Unlike dmd - gdc (the front end language) doesn't know/doesn't care about what precise platform/target it is compiling for from within gcc's framework. It may know features of the target - pointer size, real type, va_list, which direction the stack grows - just not enough to know which architecture to interpret for. So writing an assembler for ARM was an interesting exercise, but gave zero brownie points in terms of usefulness.

Am 14.12.2013 20:33, schrieb Walter Bright:
> On 12/14/2013 9:37 AM, Paulo Pinto wrote:
>> On Saturday, 14 December 2013 at 17:12:16 UTC, bearophile wrote:
>>> Dicebot:
>>>
>>>
>>>
>>>> @safe is a joke for barebone, you almost never be able to apply it :)
>>>
>>> I think you can have some safe functions in C-style code too :-)
>>
>> Yes, given my experience in Turbo Pascal and Oberon, there are lots of
>> places in
>> C-style code that code be safe as well.
>>
>> For example, there are very few places where dark magic pointer tricks
>> are
>> really essential.
>>
>> Only those code sections really need to be unsafe.
>
> Pretty much all use of pointers in C is unsafe because C cannot
> statically (or dynamically) verify that the pointers point to valid
> data, or that arithmetic on those pointers will result in pointers to
> valid data.
>
> This is the huge advantage that D's dynamic arrays have.

Yes, similar to what is known as open arrays in those languages.

>
> You can write safe code in C, but you cannot mechanically verify it as
> safe.

True, even with the help of static analysers, it all falls apart the moment you have third party code only available in binary format as libraries.

No way to validate them in C.

This is where safer languages like D have an edge over C as well.

--
Paulo

On 12/15/2013 02:20 AM, Walter Bright wrote:
> On 12/14/2013 4:36 PM, Timon Gehr wrote:
>> I cannot cast data from my own storage allocator to immutable because the
>> behaviour will be undefined.
>>
>> http://dlang.org/const3.html
>>
>> Is this a documentation bug? What should be the actual rules?
>
> It means it's up to you to ensure it is correct.

Undefined behaviour is a term with a precise meaning. That site says that casting a reference to immutable while there are still live mutable references to memory reachable by that reference leads to undefined behaviour. It is not possible to 'ensure it is correct'.

On 12/15/2013 02:20 AM, Jesse Phillips wrote:
> On Sunday, 15 December 2013 at 00:36:31 UTC, Timon Gehr wrote:
>> I cannot cast data from my own storage allocator to immutable because
>> the behaviour will be undefined.
>>
>> http://dlang.org/const3.html
>>
>> Is this a documentation bug? What should be the actual rules?
>
> Casting to immutable is defined, it is modifying the data which is not.
> That is to say, by casting to immutable the compiler cannot guarantee no
> mutation will occur. I assume you're confusion comes from:
>
>      char[] s = ...;
>      immutable(char)[] p = cast(immutable)s;     // undefined behavior
>      immutable(char)[] p = cast(immutable)s.dup; // ok, unique reference
>
> The docs should probably be cleaned up, but it isn't exactly incorrect,
> since a mutable reference exists the compiler can't really define what
> behavior will occur if the program is run because it can't guarantee
> what behavior exists.

http://en.wikipedia.org/wiki/Humpty_Dumpty#In_Through_the_Looking-Glass

On Sunday, 15 December 2013 at 11:52:17 UTC, Timon Gehr wrote:
> On 12/15/2013 02:20 AM, Walter Bright wrote:
>> On 12/14/2013 4:36 PM, Timon Gehr wrote:
>>> I cannot cast data from my own storage allocator to immutable because the
>>> behaviour will be undefined.
>>>
>>> http://dlang.org/const3.html
>>>
>>> Is this a documentation bug? What should be the actual rules?
>>
>> It means it's up to you to ensure it is correct.
>
> Undefined behaviour is a term with a precise meaning. That site says that casting a reference to immutable while there are still live mutable references to memory reachable by that reference leads to undefined behaviour. It is not possible to 'ensure it is correct'.

being picky with words is not the right way to argue :D

anyhow.
since we are programmers we can change meaning perfectly well
<code>
alias good bad;
</code> there :D

Undefined behaviour may have a precise meaning to a academic, but for me as a programmer it means. AVOID THIS SITUATION !!! unless you know what you do!
Undefined behaviour for a compiler is a point where certin garuntees MAY be broken. casting something says : "Compiler my friend: Trust Me, I know what I do"  and since neither the compiler nor the compiler-writer can know wether you are REALLY trustworthy it can't and doesn't define behaviour for that case.


In this case you have to picture langauge as obeying the open-closed principle.
The advice Walter gave was adding to the avilable Information not subsituting it.

On 12/15/2013 3:52 AM, Timon Gehr wrote:
> On 12/15/2013 02:20 AM, Walter Bright wrote:
>> On 12/14/2013 4:36 PM, Timon Gehr wrote:
>>> I cannot cast data from my own storage allocator to immutable because the
>>> behaviour will be undefined.
>>>
>>> http://dlang.org/const3.html
>>>
>>> Is this a documentation bug? What should be the actual rules?
>>
>> It means it's up to you to ensure it is correct.
>
> Undefined behaviour is a term with a precise meaning. That site says that
> casting a reference to immutable while there are still live mutable references
> to memory reachable by that reference leads to undefined behaviour. It is not
> possible to 'ensure it is correct'.

You, as the guy who wrote the code, will (or should) know that there are no other live references, hence you are telling the compiler "trust me, I know there aren't any".

> Undefined behaviour may have a precise meaning to a academic, but
for me as a programmer it means. AVOID THIS SITUATION !!! unless
you know what you do!

And to the compiler writer it means: In this situation, you can do whatever the hell you want! Later, when you think you know what you are doing, it can turn out that what some specific compiler does in some specific situation is not even remotely what you were expecting it to do. For example, see gcc and its insane behavior when -fstrict-aliasing (turned on by default at -O2) is used.