The bug is at your site. You don't make string copies and work on a single string.
char[] a = "AAA";
char[] b = a; // both point to the same location
a[0] = '!';
assert(b[0] == '!'); // should be true since they both point to the same location
Same example in C (this may help understand better):
char* str = "AAA";
char* ptr = str;
str[0] = '!';
assert(ptr[0] == '!');
The actual bug is that the following line should not compile:
char[] a = "AAA";
Problem is, D1 doesn't have invariant type modifier and the spec is frozen, so this will never be fixed. D2, however, doesn't allow you to do this.
Solution would be to make copies explicitly:
a = new FooChar("AAA".dup);
Comment #3 by bus_dbugzilla — 2008-10-14T20:34:40Z
(In reply to comment #2)
> The bug is at your site. You don't make string copies and work on a single
> string.
>
> char[] a = "AAA";
> char[] b = a; // both point to the same location
> a[0] = '!';
> assert(b[0] == '!'); // should be true since they both point to the same
> location
>
> Same example in C (this may help understand better):
> char* str = "AAA";
> char* ptr = str;
> str[0] = '!';
> assert(ptr[0] == '!');
>
I don't think that's applicable (or at least, it shouldn't be). Here's a shortened example:
char[] a = "AAA";
a[0] = '!';
char[] b = "AAA";
It's absurd that 'b' should become "!AA". It's clear that the compiler is "optimizing" both "AAA" string literals into the same reference:
char[] _tmp1 = "AAA";
char[] a = _tmp1;
a[0] = '!';
char[] b = _tmp1;
But I'm saying that transformation should not be occurring. The two "AAA" literals should not share the same reference. In D2, array literals are immutable, so yes, in D2 it works out fine. But in D1, array literals are *not* immutable, so the compiler shouldn't assume that array literals with a equal *value* can safely share the same *reference*.
> The actual bug is that the following line should not compile:
> char[] a = "AAA";
Again, this is for D1, so the idea of strings being immutable doesn't apply.
Besides, at the very least there's still an inconsistency:
char[] a = "AAA";
a[0] = '!';
char[] b = "AAA"; // b is "!AA"
char[] c = ['A', 'A', 'A'];
c[0] = '!';
char[] d = ['A', 'A', 'A']; // d is "AAA"
The above shows that two occurrences of "AAA" share the same reference, but two occurrences of ['A', 'A', 'A'] have separate references. The former leads to odd side-effects, the latter does not.
Comment #4 by 2korden — 2008-10-15T00:02:37Z
> ------- Comment #3 from [email protected] 2008-10-14
>
> I don't think that's applicable (or at least, it shouldn't be). Here's a
> shortened example:
>
> char[] a = "AAA";
> a[0] = '!';
> char[] b = "AAA";
>
> It's absurd that 'b' should become "!AA".
Well, that's what I expect, at least :)
> It's clear that the compiler is
> "optimizing" both "AAA" string literals into the same reference:
>
> char[] _tmp1 = "AAA";
> char[] a = _tmp1;
> a[0] = '!';
> char[] b = _tmp1;
Of course it does! This string literal is put into executable. "AAA" is just a pointer to it.
Please, understand that char[] is nothing more than a pointer to a string and an associated length. When you change the string via pointer, everyone who has that pointer gets the change. Compare to object:
class A
{
int i = 15;
}
A aaa = new A(); // aaa is an analog of "AAA"
A a = aaa;
writefln(a); // prints 15
a.i = 42;
A b = aaa;
writefln(b); // why the hell it prints 42????
This is because you don't make a copy of aaa.
Here is another example:
while (true) {
char[] a = "AAA";
a[0] = '!'; // in the next iteration, should a be "AAA" again?
}
If answer is yes, then there should be a memory allocation in line 2 under the hood. You can't get new string every time without a memory allocation. This, however, definitely should not occur. If you want to make an allocation - do it yourself explicitely.
Code with the behaviour you expect should be as follows:
while (true) {
char[] a = "AAA".dup;
writefln(a);
a[0] = '!';
writefln(a);
}
This is by design, it works as it should. It can't be 'fixed' because it is not broken.
> Besides, at the very least there's still an inconsistency:
>
> char[] a = "AAA";
> a[0] = '!';
> char[] b = "AAA"; // b is "!AA"
>
> char[] c = ['A', 'A', 'A'];
> c[0] = '!';
> char[] d = ['A', 'A', 'A']; // d is "AAA"
I agree, this might be a bug, d really ought to be "!AAA"!
Do you want to create a new bugreport so that the latter case would be 'fixed'? :)
Comment #5 by kamm-removethis — 2008-10-15T02:36:57Z
The D spec says "String literals are immutable (read only)." even in D1. So code like this
char[] a = "ABC";
a[0] = '!';
is illegal (and will segfault on linux!).
Array literals are allocated on the heap (the D spec explicitly says so) and will thus behave fundamentally different from string literals.
Comment #6 by bus_dbugzilla — 2008-10-15T05:13:03Z
(In reply to comment #5)
> The D spec says "String literals are immutable (read only)." even in D1. So
> code like this
>
> char[] a = "ABC";
> a[0] = '!';
>
> is illegal (and will segfault on linux!).
>
> Array literals are allocated on the heap (the D spec explicitly says so) and
> will thus behave fundamentally different from string literals.
>
Alright, I see now. It does seem odd though that array literals would carry a type that lacks any sort of const/read-only/immutable/etc qualifier, but is still immutable anyway. Just another of D2's improvements I guess.
Out of curiosity, any idea if the lack of a run-time error on windows is due to windows itself or just something DMD/OPTLINK does differently between the platforms?