November 03, 2011
On 02.11.2011 22:19, deadalnix wrote:
> Le 31/10/2011 21:25, Timon Gehr a écrit :
>> On 10/31/2011 08:34 PM, bearophile wrote:
>>> I don't see the need to accept this cast, because we have said that D
>>> arrays are not pointers, and allowing the array to pointer cast means
>>> introducing/leaving an useless special case, and in practice this
>>> special case is not useful because arrays have the ptr property:
>>>
>>
>> extern(C) void foo(char* str);
>> foo(cast(char*)"hello");
>>
>>
>>>
>>> struct Foo {
>>> int* p;
>>> size_t n;
>>> }
>>> void main() {
>>> Foo f;
>>> auto x = f.ptr; // OK
>>> }
>>>
>>
>> Actually compile error :o).
>>
>>>
>>> So I think cast(int*)a1 should be forbidden.
>>
>> -1. I don't really see any point in disallowing it. It is an explicit
>> cast, not some kind of bug prone implicit behaviour.
>>
>
> Well, because the ptr property is done for that. Actually, D ABI says
> that the struct representing the array begins with length, then prt, so
> the result isn't obvious from a low level perspective, which is kinda
> sad when it goes to pointer manipulation.

The fix has already been implemented in git master. The bug report is closed.
There's no point commenting on this topic further.

November 05, 2011
On Sun, 30 Oct 2011 17:29:36 -0400, bearophile wrote:

> 
> Do you see the bug I have found during the debugging?
> 
> I think the D2 compiler has to catch this bug:
> 
> *array = ...;
> 

It is not a bug, it is a feature. If you really do not like it, use the .ptr property. :)
November 06, 2011
On 05.11.2011 12:35, Dejan Lekic wrote:
> On Sun, 30 Oct 2011 17:29:36 -0400, bearophile wrote:
>
>>
>> Do you see the bug I have found during the debugging?
>>
>> I think the D2 compiler has to catch this bug:
>>
>> *array = ...;
>>
>
> It is not a bug, it is a feature. If you really do not like it, use
> the .ptr property. :)

It was a bug. And it's now been fixed.
November 07, 2011
Don wrote:

> 
> It was a bug. And it's now been fixed.

Don, care to explain why? If I want to treat D's array like I would do in C, why not allow me do so?
November 09, 2011
On 07.11.2011 10:45, Dejan Lekic wrote:
> Don wrote:
>
>>
>> It was a bug. And it's now been fixed.
>
> Don, care to explain why? If I want to treat D's array like I would do in C,
> why not allow me do so?

I had no involvement with it at all.

Although, when we originally banned implicit conversions from arrays to pointers, it was because it was _the_ most common bug in D code. Especially when you pass a char[] array to an extern(C) function that accepts a char *. It really was a disaster.

Just add .ptr if you want to convert it to a pointer. It's beautiful, really.
May 13, 2023

On Monday, 31 October 2011 at 20:26:35 UTC, Timon Gehr wrote:

>

On 10/31/2011 08:34 PM, bearophile wrote:

>

Kenji Hara (and the D community) is really good, he has already written a pull request with the bug fix:
https://github.com/D-Programming-Language/dmd/pull/483


Kenji Hara has fixed about 1/3 of the issue, so he asked me to split the but report, this is a spin off:
http://d.puremagic.com/issues/show_bug.cgi?id=6869

In DMD 2.056 this code compiles:

void main() {
int[] a1 = [5, 4, 3];
int* p1 = cast(int*)a1; // no compile error here
}

Similar code using user-created struct doesn't compile:

struct Foo {
int* p;
size_t n;
}
void main() {
Foo f;
auto x = cast(int*)f; // compile error here
}

That is not similar code. This is:

struct Foo {
size_t length;
int* ptr;
T opCast(T: int*)(){return ptr;}
}

void main() {
Foo f;
auto x = cast(int*)f; // no compile error here
}

>

I don't see the need to accept this cast, because we have said that D arrays are not pointers, and allowing the array to pointer cast means introducing/leaving an useless special case, and in practice this special case is not useful because arrays have the ptr property:

extern(C) void foo(char* str);
foo(cast(char*)"hello");

>

struct Foo {
int* p;
size_t n;
}
void main() {
Foo f;
auto x = f.ptr; // OK
}

Actually compile error :o).

>

So I think cast(int*)a1 should be forbidden.

-1. I don't really see any point in disallowing it. It is an explicit cast, not some kind of bug prone implicit behaviour.

>

The third part of the bug report was part of this older one:
http://d.puremagic.com/issues/show_bug.cgi?id=3971

The idea is to forbid code like:

void main() {
int[3] a;
a = 1;
assert(a == [1, 1, 1]);
}

And require the square brackets every time an array operation is performed, for syntactic uniformity with the other vector ops, and to avoid mistakes:

void main() {
int[3] a;
a[] = 1;
assert(a == [1, 1, 1]);
}

+1. That helps static type safety a bit and forces code to be more readable.

I saw that it was closed today:

https://issues.dlang.org/show_bug.cgi?id=6869

Sorry for reviving an old thread. But I have to think that the problem will not be seen in newer versions?

Thanks...

SDB@79

May 13, 2023

On Saturday, 13 May 2023 at 12:55:24 UTC, Salih Dincer wrote:

>

I saw that it was closed today:

https://issues.dlang.org/show_bug.cgi?id=6869

A new issue has been reported by Steven Schveighoffer:

https://issues.dlang.org/show_bug.cgi?id=23919

>

Casting an array to a pointer is allowed:

import core.stdc.stdio;
auto str = "hello";
printf(cast(char *)str[0 .. 3]);

This prints "hello".

The user might think they have properly matched the requirements, but in
actuality, all they have done is accessed the pointer.

A few reasons why this is bad:

  1. It's trivial (and more readable) to use .ptr instead of the cast
  2. The cast must match the attributes or risk causing problems when code
    evolves. Casting is a blunt instrument, and should be discouraged when
    better alternatives exist.
  3. The cast gives a false impression that something is happening underneath
    to ensure the data is correct. Many C functions require pointers instead of
    arrays, and this "seems" like the right answer.

I think we should deprecate this "feature". I'm not exactly sure why this
was needed in the first place.

I know a previous issue #6869 was closed as WONTFIX. I'm opening this to
hopefully reconsider the decision.

FWIW, the D discord has had a few people coming to ask why their code
doesn't work when casting a string to a char *.

I would pair such a cast error with a suggestion to use toStringz in the
case of string to char * conversions.

SDB@79

1 2 3
Next ›   Last »