www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is &array[0] safer than array.ptr?

reply Atila Neves <atila.neves gmail.com> writes:
void main() {
     foo;
}

void foo()  safe {
     int[] array;
     auto ptr = array.ptr;
}


foo.d(7): Deprecation: array.ptr cannot be used in  safe code, 
use &array[0] instead


&array[0] is incredibly ugly and feels like an unnecessary hack, 
and I'm wondering why it's  safe.

Atila
Jan 24 2017
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
 void main() {
     foo;
 }

 void foo()  safe {
     int[] array;
     auto ptr = array.ptr;
 }


 foo.d(7): Deprecation: array.ptr cannot be used in  safe code, 
 use &array[0] instead


 &array[0] is incredibly ugly and feels like an unnecessary 
 hack, and I'm wondering why it's  safe.

 Atila
the type is still a type with bounds and not an unbounded pointer.
Jan 24 2017
prev sibling next sibling parent reply TheFlyingFiddle <kurtyan student.chalmers.se> writes:
On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
 void main() {
     foo;
 }

 void foo()  safe {
     int[] array;
     auto ptr = array.ptr;
 }


 foo.d(7): Deprecation: array.ptr cannot be used in  safe code, 
 use &array[0] instead


 &array[0] is incredibly ugly and feels like an unnecessary 
 hack, and I'm wondering why it's  safe.

 Atila
Just a speculative guess. unittest safe { int[] array; auto ptr = array.ptr; //could be null auto ptr2 = &array[0]; //Does a bounds check? auto ptr3 = &array[5]; //Should do a bounds check. }
Jan 24 2017
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 24 January 2017 at 11:32:47 UTC, TheFlyingFiddle 
wrote:
 On Tuesday, 24 January 2017 at 11:28:17 UTC, Atila Neves wrote:
 void main() {
     foo;
 }

 void foo()  safe {
     int[] array;
     auto ptr = array.ptr;
 }


 foo.d(7): Deprecation: array.ptr cannot be used in  safe code, 
 use &array[0] instead


 &array[0] is incredibly ugly and feels like an unnecessary 
 hack, and I'm wondering why it's  safe.

 Atila
Just a speculative guess. unittest safe { int[] array; auto ptr = array.ptr; //could be null auto ptr2 = &array[0]; //Does a bounds check? auto ptr3 = &array[5]; //Should do a bounds check. }
&array[5] makes sense to bounds check, and I guess then the issue is I could instead do `array.ptr + 5` which would be bad. But it's still annoying to have to do &array[0] just to pass it to a C function, since `my_c_func(array.ptr)` isn't going to screw up anything. BTW, in that example above array.ptr is null even though array is null. It doesn't crash. Atila
Jan 24 2017
parent David Nadlinger <code klickverbot.at> writes:
On Tuesday, 24 January 2017 at 11:49:59 UTC, Atila Neves wrote:
 But it's still annoying to have to do &array[0] just to pass it 
 to a C function, since `my_c_func(array.ptr)` isn't going to 
 screw up anything.
How do you know it does not screw up anything? Presumably, the function somehow accesses the object the pointer targets. How would this be safe to call if the pointer were not dereferencable? — David
Jan 25 2017
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Tuesday, January 24, 2017 11:28:17 Atila Neves via Digitalmars-d-learn 
wrote:
 void main() {
      foo;
 }

 void foo()  safe {
      int[] array;
      auto ptr = array.ptr;
 }


 foo.d(7): Deprecation: array.ptr cannot be used in  safe code,
 use &array[0] instead


 &array[0] is incredibly ugly and feels like an unnecessary hack,
 and I'm wondering why it's  safe.
Likely because it does bounds checking, so you at least know that it's not null. But I don't see why that would really improve much considering that the odds are that you're really going to be accessing far more than just the first element with the pointer. It seems _slightly_ better from a safety perspective but only slightly. So, I don't know what the point is in suggesting it as an alternative. - Jonathan M Davis
Jan 24 2017
next sibling parent reply Rene Zwanenburg <renezwanenburg gmail.com> writes:
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis 
wrote:
 Likely because it does bounds checking, so you at least know 
 that it's not null. But I don't see why that would really 
 improve much considering that the odds are that you're really 
 going to be accessing far more than just the first element with 
 the pointer. It seems _slightly_ better from a safety 
 perspective but only slightly. So, I don't know what the point 
 is in suggesting it as an alternative.

 - Jonathan M Davis
Pointer arithmetic is forbidden in safe code so that's not a problem. The reason this was introduced was indeed bounds checking. For example: safe: int parse(ref char[] input) { // Pop all numeric characters from the front of the input slice and convert to int } void main() { auto input = "123".dup; parse(input); // Since all numeric chars have been popped, input is now effectively input[$ .. $]. // This means input.ptr is pointing past the end of the array. writeln(input.ptr); // Out of bounds access }
Jan 24 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Tuesday, January 24, 2017 11:50:16 Rene Zwanenburg via Digitalmars-d-
learn wrote:
 On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis

 wrote:
 Likely because it does bounds checking, so you at least know
 that it's not null. But I don't see why that would really
 improve much considering that the odds are that you're really
 going to be accessing far more than just the first element with
 the pointer. It seems _slightly_ better from a safety
 perspective but only slightly. So, I don't know what the point
 is in suggesting it as an alternative.

 - Jonathan M Davis
Pointer arithmetic is forbidden in safe code so that's not a problem. The reason this was introduced was indeed bounds checking. For example: safe: int parse(ref char[] input) { // Pop all numeric characters from the front of the input slice and convert to int } void main() { auto input = "123".dup; parse(input); // Since all numeric chars have been popped, input is now effectively input[$ .. $]. // This means input.ptr is pointing past the end of the array. writeln(input.ptr); // Out of bounds access }
Sure, there can be problems with .ptr. It's not necessarily a problem that it's not safe. But doing &arr[0] instead of arr.ptr is almost pointless. All it does is verify that the array isn't null or empty. If you're doing arr.ptr, you're almost certainly passing it to C code, and that code will almost certainly read well past the arr[0]. So, while it makes sense to say that .ptr can't be used in safe code, it really doesn't make sense to suggest &arr[0] as an alternative. - Jonathan M Davis
Jan 24 2017
next sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis 
wrote:
 So, while it makes sense to say that .ptr can't be used in 
  safe code, it really doesn't make sense to suggest &arr[0] as 
 an alternative.
That may well be. But I believe everything that can provably be safe are made so even when apparently pointeless, because someone may find creative uses for those things. Ones the creators did not think of. And even if there are none now, that may change in the future with the language or libraries.
Jan 24 2017
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis 
wrote:
 So, while it makes sense to say that .ptr can't be used in 
  safe code, it really doesn't make sense to suggest &arr[0] as 
 an alternative.
When you ensure pointers point to existing data, you can dereference them in safe code, otherwise you can't.
Jan 25 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, January 25, 2017 10:52:51 Kagamin via Digitalmars-d-learn 
wrote:
 On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis

 wrote:
 So, while it makes sense to say that .ptr can't be used in
  safe code, it really doesn't make sense to suggest &arr[0] as
 an alternative.
When you ensure pointers point to existing data, you can dereference them in safe code, otherwise you can't.
Fine, but in the vast majority of cases, you're calling .ptr, because you're going to be passing the pointer to C code, in which case, doing &arr[0] buys you very little, since the C code is inevitably going to be reading more than that one element, and &arr[0] hasn't verified anything beyond the first element. So, telling the programmer to use &arr[0] instead of arr.ptr is just plain bizarre. Doing &arr[0] makes sense when you're just going to be messing with that one element in D code, but that's pretty much it. Otherwise, you might as well just use arr.ptr, because it's up to the programmer to verify the safety of what's going on at that point anyway. - Jonathan M Davis
Jan 25 2017
parent David Nadlinger <code klickverbot.at> writes:
On Wednesday, 25 January 2017 at 18:12:18 UTC, Jonathan M Davis 
wrote:
 Fine, but in the vast majority of cases, you're calling .ptr, 
 because you're going to be passing the pointer to C code, in 
 which case, doing &arr[0] buys you very little, since the C 
 code is inevitably going to be reading more than that one 
 element,
In that case, calling the C function isn't going to be safe anyway, so you might as well use .ptr.
 So, telling the programmer to use &arr[0] instead of arr.ptr is 
 just plain bizarre.
What you call bizarre is a simple, actionable explanation (which is especially important as the behaviour was necessarily a backwards-incompatible change). If &arr[0] doesn't actually apply to your code, then it was mistakenly safe before. — David
Jan 25 2017
prev sibling parent Jerry <Kickupx gmail.com> writes:
On Tuesday, 24 January 2017 at 12:01:35 UTC, Jonathan M Davis 
wrote:
 So, while it makes sense to say that .ptr can't be used in 
  safe code, it really doesn't make sense to suggest &arr[0] as 
 an alternative.

 - Jonathan M Davis
Sure I see your point. But I feel like deprecations should also list what one can do instead. So in that regard the suggestion makes sense.
Jan 25 2017
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis 
wrote:
 It seems _slightly_ better from a safety perspective but only 
 slightly.
Wrong – one is correct, the other is not. This is because every pointer in SafeD is dereferencable. Pointer arithmetic is not allowed in SafeD, so your concerns about reading from other memory do not apply. — David
Jan 25 2017
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger 
wrote:
 This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either arr[0] or null....
Jan 25 2017
parent reply David Nadlinger <code klickverbot.at> writes:
On Wednesday, 25 January 2017 at 22:54:32 UTC, Adam D. Ruppe 
wrote:
 On Wednesday, 25 January 2017 at 22:46:10 UTC, David Nadlinger 
 wrote:
 This is because every pointer in SafeD is dereferencable.
But null pointers are allowed in SafeD and arr.ptr is either arr[0] or null....
This is a fallacy: --- safe: // Deprecated, though. ubyte oops(ubyte[] b) { return *b.ptr; } void main() { oops(new ubyte[0]); // - or - auto b = new ubyte[42]; oops(b[$ .. $]); } --- — David
Jan 25 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 25 January 2017 at 23:09:11 UTC, David Nadlinger 
wrote:
 This is a fallacy:
Ah, yes indeed, that was mentioned earlier in the thread too, it just slipped my mind again.
Jan 25 2017
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Wednesday, January 25, 2017 22:46:10 David Nadlinger via Digitalmars-d-
learn wrote:
 On Tuesday, 24 January 2017 at 11:38:16 UTC, Jonathan M Davis

 wrote:
 It seems _slightly_ better from a safety perspective but only
 slightly.
Wrong – one is correct, the other is not. This is because every pointer in SafeD is dereferencable. Pointer arithmetic is not allowed in SafeD, so your concerns about reading from other memory do not apply.
Yes, but my point is that you're normally only going to use .ptr to pass something to a C function, and even if you're doing more with it in D, odds are, you're going to be doing pointer arithmetic. All &arr[0] does over arr.ptr is check the first element. It makes it safe, but then everything else you're going to be doing after that almost certainly won't be safe. And when you combine it with marking C function trusted, this is actually pretty bad. It makes it trivial to do something like extern(C) int cFunc(int* ptr, size_t length) trusted; auto result = cFunc(&arr[0], 12); and have it be considered safe, when it's not safe at all. Now, most code would then do auto result = cFunc(&arr[0], arr.length); so in practice, it won't usally be a problem, but it makes it easy to have code treated like it's completely safe when in fact it isn't. Now, really, the fix there is to not mark the C function as trusted and require that the caller make sure they pass in arguments that are safe, but at least if they were doing auto result = cFunc(arr.ptr, arr.length); the compiler would have caught that it was system even with the C function being marked as trusted, whereas if you do &arr[0], it wouldn't. So, yes, if all you're planning to do is look at the pointer to the first element in the array, then &arr[0] is safer, but odds are quite low that that's actually what you're going to do, and in all of the other cases, you might as well just use .ptr. So, telling folks to go use &arr[0] instead of .ptr doesn't seem very helpful to me. - Jonathan M Davis
Jan 25 2017
next sibling parent David Nadlinger <code klickverbot.at> writes:
On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis 
wrote:
 Yes, but my point is that you're normally only going to use 
 .ptr to pass something to a C function, and even if you're 
 doing more with it in D, odds are, you're going to be doing 
 pointer arithmetic.
Wrong again. If this were the case, we wouldn't have needed to make it a deprecation at all, since all uses would have been mistakes. A non-negligible amount of real-world D code actually uses single-object pointers. Look up the change history if you are interested – and indeed, making sure one understands the topic sufficiently well to meaningfully contribute before typing out a wall-length sermon would collectively save us a good chunk of time.
 And when you combine it with marking C function  trusted, this 
 is actually pretty bad.
Ex falso quodlibet – once you have a piece of code mistakenly marked trusted, all guarantees are out of the window even without suspicious-looking client code. safe-ty is about mechanically verifiable code, not faith-based programming. — David
Jan 25 2017
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Wednesday, 25 January 2017 at 22:59:55 UTC, Jonathan M Davis 
wrote:
 So, yes, if all you're planning to do is look at the pointer to 
 the first element in the array, then &arr[0] is safer, but odds 
 are quite low that that's actually what you're going to do, and 
 in all of the other cases, you might as well just use .ptr. So, 
 telling folks to go use &arr[0] instead of .ptr doesn't seem 
 very helpful to me.
Pehaps it should say something like: arr.ptr is deprecated in safe code. Use &arr[0] for checked access or remove the safe attribute. That would make it clear that .ptr is not an issue, only .ptr in safe.
Jan 26 2017