www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - arr.ptr, safe and void*

reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
Hi,
Walter's made a fix for arr[$..$].ptr being unsafe to dereference 
- .ptr will be  system:
https://github.com/dlang/dmd/pull/5860

A referenced druntime pull mentioned having a safe wrapper for 
.ptr that allows comparison of the pointer value, but does not 
allow dereference. The wrapper would return uintptr_t (an integer 
guaranteed to be big enough to hold a pointer value).

My question is: would returning void* instead really be unsafe, 
i.e. is there a way of dereferencing it in safe code? (I'm not 
thinking about holes in  safe, but ways by design).
Jun 15 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/15/16 6:32 AM, Nick Treleaven wrote:

 Hi,
 Walter's made a fix for arr[$..$].ptr being unsafe to dereference - .ptr
 will be  system:
 https://github.com/dlang/dmd/pull/5860

 A referenced druntime pull mentioned having a safe wrapper for ..ptr
 that allows comparison of the pointer value, but does not allow
 dereference. The wrapper would return uintptr_t (an integer guaranteed
 to be big enough to hold a pointer value).

 My question is: would returning void* instead really be unsafe, i.e. is
 there a way of dereferencing it in safe code? (I'm not thinking about
 holes in  safe, but ways by design).


Yes. If the meaning of this expression is different in  safe vs. 
 system, then compiler inference can affect code drastically:

auto d = arr1.ptr - arr2.ptr;

The PR I think you are referring to is mine: 
https://github.com/dlang/druntime/pull/1592

And this would be able to solve the problem, but I don't know if it's 
ready for prime time (proposed to be in core.internal).

-Steve
Jun 15 2016
parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On Wednesday, 15 June 2016 at 17:35:49 UTC, Steven Schveighoffer 
wrote:

 On 6/15/16 6:32 AM, Nick Treleaven wrote:

 My question is: would returning void* instead really be 
 unsafe, i.e. is
 there a way of dereferencing it in safe code? (I'm not 
 thinking about
 holes in  safe, but ways by design).


 Yes. If the meaning of this expression is different in  safe 
 vs.  system, then compiler inference can affect code 
 drastically:

 auto d = arr1.ptr - arr2.ptr;


I probably wasn't clear - I'm not suggesting .ptr returns void*, 
I agree with you. But I don't get why arr.ptrValue can't be safe 
and return void* instead of uintptr_t.


 The PR I think you are referring to is mine: 
 https://github.com/dlang/druntime/pull/1592

 And this would be able to solve the problem, but I don't know 
 if it's ready for prime time (proposed to be in core.internal).


I did see this, it's interesting. I suppose the advantage over 
ptrValue would be type safety.
Jun 15 2016
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/15/16 4:08 PM, Nick Treleaven wrote:

 On Wednesday, 15 June 2016 at 17:35:49 UTC, Steven Schveighoffer wrote:

 On 6/15/16 6:32 AM, Nick Treleaven wrote:

 My question is: would returning void* instead really be unsafe, i.e. is
 there a way of dereferencing it in safe code? (I'm not thinking about
 holes in  safe, but ways by design).


 Yes. If the meaning of this expression is different in  safe vs.
  system, then compiler inference can affect code drastically:

 auto d = arr1.ptr - arr2.ptr;


 I probably wasn't clear - I'm not suggesting .ptr returns void*, I agree
 with you. But I don't get why arr.ptrValue can't be safe and return
 void* instead of uintptr_t.


It could probably do this. Dereferencing a void * isn't valid, so it 
kind of has the same effect. However, there are many functions which 
take void * and do write to/read from the data pointing at it (e.g. 
memcpy). These aren't  safe, so they should be off-limits.

The original fix proposed by Walter was to return const(void)*. This 
probably would have been fine, Daniel objected to it, but he may have 
been thrown off by the comment in the code which said "Ok because the 
user will never dereference the pointer", hinting the user may have a 
choice to do so. Hard to tell.

But the nice thing about returning a non-pointer is that you can't 
accidentally use it in cases where your code is  system or  trusted. It 
states clearly "I only care about the location of this memory, not 
what's in it". There is some value in that.

-Steve
Jun 15 2016
parent Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On Wednesday, 15 June 2016 at 20:33:54 UTC, Steven Schveighoffer 
wrote:

 It could probably do this. Dereferencing a void * isn't valid, 
 so it kind of has the same effect. However, there are many 
 functions which take void * and do write to/read from the data 
 pointing at it (e.g. memcpy). These aren't  safe, so they 
 should be off-limits.

 [...]


OK, thanks for explaining ;-)
Jun 16 2016