Re: arr.ptr, @safe and void*
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 ;-)
Re: arr.ptr, @safe and void*
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
Re: arr.ptr, @safe and void*
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.
Re: arr.ptr, @safe and void*
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
arr.ptr, @safe and void*
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).
