www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pure functions and pointers (yes, again)

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
Since issue 8185 has been closed, I'm still very confused. I just 
understood that endless discussion doesn't result in anything.

See example from http://d.puremagic.com/issues/show_bug.cgi?id=8185#c40
---
int f(size_t p) pure
{
     return *cast(int*) p;
}

void g(size_t p, ref size_t) pure
{
     ++*cast(int*) p;
}

void h(size_t a, size_t b) pure
{
     int res = f(a);
     g(b, b);
     assert(res == f(a)); // may fail, no guaranties by language!
}

void main()
{
     int a;
     h(cast(size_t) &a, cast(size_t) &a);
}
---

Jonathan M Davis (whose documentation correcting pull closed the issue) 
told me that this code result in undefined behaviour. What _exectly_ 
language rule this violates? I don't see this rule, but if there is no 
such rule, how can we treat anything as strongly pure function?

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Jul 04 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, July 04, 2012 11:59:10 Denis Shelomovskij wrote:

 Since issue 8185 has been closed, I'm still very confused. I just
 understood that endless discussion doesn't result in anything.
 
 See example from http://d.puremagic.com/issues/show_bug.cgi?id=8185#c40
 ---
 int f(size_t p) pure
 {
      return *cast(int*) p;
 }
 
 void g(size_t p, ref size_t) pure
 {
      ++*cast(int*) p;
 }
 
 void h(size_t a, size_t b) pure
 {
      int res = f(a);
      g(b, b);
      assert(res == f(a)); // may fail, no guaranties by language!
 }
 
 void main()
 {
      int a;
      h(cast(size_t) &a, cast(size_t) &a);
 }
 ---
 
 Jonathan M Davis (whose documentation correcting pull closed the issue)
 told me that this code result in undefined behaviour. What _exectly_
 language rule this violates? I don't see this rule, but if there is no
 such rule, how can we treat anything as strongly pure function?


You're violating the type system. You've claimed that a size_t is a pointer by 
casting it to one and then operating on it as if it were one. Whether the 
value was originally a pointer or not is irrelevant. You've lied to the 
compiler about the type, which means that you've subverted the type system, 
and it's up to _you_ to guarantee that the guarantees that the compiler is 
supposed to be making hold. The compiler has to use the type system to make 
its gurantees, so if you lie to it about types, it will make incorrect 
assumptions, you'll end up with wrong code, and it'll be your fault.

It's like with const. Don't cast away const and then modify the variable. It's 
undefined behavior. Don't do it. You're lying to the compiler about types, and 
it bases its guarantees on types. So, if you've lied to it, _of course_ it's 
going to break.

D is a systems language, so you can do really dirty things in  system code if 
you need to, but don't expect the compiler to magically figure out what you're 
doing when you're lying to it through casts.

- Jonathan M Davis
Jul 04 2012
prev sibling parent reply travert phare.normalesup.org (Christophe Travert) writes:
Denis Shelomovskij , dans le message (digitalmars.D:171072), a écrit :

 Since issue 8185 has been closed, I'm still very confused. I just 
 understood that endless discussion doesn't result in anything.
 
 See example from http://d.puremagic.com/issues/show_bug.cgi?id=8185#c40
 ---
 int f(size_t p) pure
 {
      return *cast(int*) p;
 }
 
 void g(size_t p, ref size_t) pure
 {
      ++*cast(int*) p;
 }
 
 void h(size_t a, size_t b) pure
 {
      int res = f(a);
      g(b, b);
      assert(res == f(a)); // may fail, no guaranties by language!
 }
 
 void main()
 {
      int a;
      h(cast(size_t) &a, cast(size_t) &a);
 }
 ---
 
 Jonathan M Davis (whose documentation correcting pull closed the issue) 
 told me that this code result in undefined behaviour. What _exectly_ 
 language rule this violates? I don't see this rule, but if there is no 
 such rule, how can we treat anything as strongly pure function?


Casting a value to a pointer clearly subvert the type system. A value 
with no reference (like size_t) is convertible to immutable, but a 
pointer cannot. Thus, a function with f's signature is strongly pure, 
but it is not if takes an int*. That's how you can create a bug.

The same issue occurs if you 'create' a pointer by illegal pointer 
arithmetic for instance: this is undefined behavior. Creating and using 
any kind reference by casting is undefined. That's not only a purity 
problem, it is a safety, a garbage collection, an and optimisation 
issue. In your case, you know what you ar doing regarding safety and 
garbage collection. Fine. But you do not respect optimisations linked 
with purity. Too bad, you can't ignore that the compiler is going to 
make assumptions regarding your datas types.

What change would you expect in the langage? making pure function 
automatically  safe? That may not be such a ba idea. However, that is 
not even enough, you could still create bug from optimizations with 
casting outside the pure function (for instance, you could alias 
variables that should not be aliased).

The only possibility to completely avoid this kind of bug is to forbid 
either optimization or casting. That's not going to happen in D.
Jul 04 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, July 04, 2012 09:21:35 Christophe Travert wrote:

 What change would you expect in the langage? making pure function
 automatically  safe? That may not be such a ba idea. However, that is
 not even enough, you could still create bug from optimizations with
 casting outside the pure function (for instance, you could alias
 variables that should not be aliased).


An  safe function is only as safe as the  trusted functions that it calls. 
With  trusted, it's up to the programmer to determine that the  system stuff 
being done is actually being done in a way which is ultimately  safe (e.g. not 
using undefined behavior). If the programmer screwed up, and the  trusted stuff 
has buffer overruns or whatnot, then the  safe code isn't really  safe. With 
both  trusted and casts, it's up to the programmer to get them right, because 
what the programmer is doing is telling the compiler that they know better 
than the compiler and that they know what they're doing. If they do know 
better, then great. But if they don't, say hello to some nasty bugs.

_All_ of the guarantees that the compiler gives are based on the type system. 
So, anything that the programmer does to work around the type system must be 
verified and guaranteed by the programmer to ultimately maintain the guarantees 
that compiler expects. Otherwise, the compiler's guarantees are based on wrong 
assumptions, and they're going to be invalid.

- Jonathan M Davis
Jul 04 2012