Re: immutable string literal?
Daniel Keep Wrote:
strtr wrote:
On winXP (D1) I can compile/run this code without a problem.
Not even a warning.
void main() {
char[] s= immutable literal?;
s[$-1] = '!';
writefln(s);
}
Codepad runs into a segmentation fault.
http://codepad.org/NQfsRoR5
Why doesn't it result in a compiler error or warning?
If it did I would have noticed this quirk earlier.
There's no compiler error because D1 doesn't have a const/immutable system.
There's no crash because Windows doesn't write-protect the data segment
which contains the literal.
But according to the specs, it does constitute an error and I suspect string
literals are placed in a specific memory location.
Wouldn't it be possible to error on such code?
Re: immutable string literal?
On Mon, 22 Feb 2010 08:32:20 -0500, strtr st...@spam.com wrote:
Daniel Keep Wrote:
strtr wrote:
On winXP (D1) I can compile/run this code without a problem.
Not even a warning.
void main() {
char[] s= immutable literal?;
s[$-1] = '!';
writefln(s);
}
Codepad runs into a segmentation fault.
http://codepad.org/NQfsRoR5
Why doesn't it result in a compiler error or warning?
If it did I would have noticed this quirk earlier.
There's no compiler error because D1 doesn't have a const/immutable
system.
There's no crash because Windows doesn't write-protect the data segment
which contains the literal.
But according to the specs, it does constitute an error and I suspect
string literals are placed in a specific memory location.
Wouldn't it be possible to error on such code?
Yes, it is possible -- use D2 which has such errors :) Without a const
system, D1 cannot distinguish between char[] that originated from a
literal (i.e. in the static data segment) or which originated from the
heap. At the point where you see the line:
s[$-1] = '!';
You don't have the entire history of where s came from. It can be even
harder to detect than you think. For instance, should you allow the
following code to compile?
int main(char[][] args)
{
char[] s;
if(args[1] == y)
s = immutable literal?;
else
s = mutable literal?.dup;
s[$-1] = !;
return 0;
}
This program runs fine unless you pass the exact argument 'y' to the
program, and then it crashes. How does the compiler know at the line
where s is modified that it could have possibly come from a literal?
If you still think it's possible, what about this?
void exclaim(char[] s)
{
s[$-1] = '!';
}
If this is in its own module, how can the compiler tell whether s is
immutable or not?
-Steve
Re: immutable string literal?
Steven Schveighoffer Wrote:
On Mon, 22 Feb 2010 08:32:20 -0500, strtr st...@spam.com wrote:
Daniel Keep Wrote:
strtr wrote:
On winXP (D1) I can compile/run this code without a problem.
Not even a warning.
void main() {
char[] s= immutable literal?;
s[$-1] = '!';
writefln(s);
}
Codepad runs into a segmentation fault.
http://codepad.org/NQfsRoR5
Why doesn't it result in a compiler error or warning?
If it did I would have noticed this quirk earlier.
There's no compiler error because D1 doesn't have a const/immutable
system.
There's no crash because Windows doesn't write-protect the data segment
which contains the literal.
But according to the specs, it does constitute an error and I suspect
string literals are placed in a specific memory location.
Wouldn't it be possible to error on such code?
Yes, it is possible -- use D2 which has such errors :) Without a const
system, D1 cannot distinguish between char[] that originated from a
literal (i.e. in the static data segment) or which originated from the
heap. At the point where you see the line:
s[$-1] = '!';
You don't have the entire history of where s came from. It can be even
harder to detect than you think. For instance, should you allow the
following code to compile?
int main(char[][] args)
{
char[] s;
if(args[1] == y)
s = immutable literal?;
else
s = mutable literal?.dup;
s[$-1] = !;
return 0;
}
This program runs fine unless you pass the exact argument 'y' to the
program, and then it crashes. How does the compiler know at the line
where s is modified that it could have possibly come from a literal?
If you still think it's possible, what about this?
void exclaim(char[] s)
{
s[$-1] = '!';
}
If this is in its own module, how can the compiler tell whether s is
immutable or not?
-Steve
Thanks, I understand.
But, how about a runtime error?
Isn't a literal placed in easy to identify should-only-read memory?
Re: immutable string literal?
Steven Schveighoffer wrote: On Mon, 22 Feb 2010 09:27:57 -0500, strtr st...@spam.com wrote: Thanks, I understand. But, how about a runtime error? Isn't a literal placed in easy to identify should-only-read memory? A segfault is a runtime error. The problem with Windows is it doesn't throw an error on writes to its data segment (unlike Linux). In reality, the result of your program is undefined, so don't expect any help from the compiler/runtime. There's nothing D1 can do about that. In order for D to intercept that, it would have to instrument every write to memory, and that would cause performance problems like you wouldn't believe. Windows can protect memory as read-only too. Why dmd doesn't do that is a mystery. Even if .exe doesn't support read-only data segments, the runtime could have done so in early start-up code. The short answer: Just don't do that. -Steve
Re: immutable string literal?
grauzone Wrote: Windows can protect memory as read-only too. Why dmd doesn't do that is a mystery. Even if .exe doesn't support read-only data segments, the runtime could have done so in early start-up code. If that is the case, then I'd suggest a(n enhancement?) bug-report :)
Re: immutable string literal?
On Mon, 22 Feb 2010 10:19:52 -0500, grauzone n...@example.net wrote: Steven Schveighoffer wrote: On Mon, 22 Feb 2010 09:27:57 -0500, strtr st...@spam.com wrote: Thanks, I understand. But, how about a runtime error? Isn't a literal placed in easy to identify should-only-read memory? A segfault is a runtime error. The problem with Windows is it doesn't throw an error on writes to its data segment (unlike Linux). In reality, the result of your program is undefined, so don't expect any help from the compiler/runtime. There's nothing D1 can do about that. In order for D to intercept that, it would have to instrument every write to memory, and that would cause performance problems like you wouldn't believe. Windows can protect memory as read-only too. Why dmd doesn't do that is a mystery. Even if .exe doesn't support read-only data segments, the runtime could have done so in early start-up code. I'm not super-familiar with windows capabilities, but I'd venture a guess that doing so would make exe's not compatible with older versions of Windows. But still, what does it matter? Just don't use D1 if you want a compiler error, or don't try and trick the system into modifying ROM! There are plenty of projects using D1 that just don't do this, and they are fine. Implementing features to help people determine they created undefined behavior is simply a waste of time. If you feel you can fix it, by all means submit a patch, and it might get in. -Steve
Re: immutable string literal?
Steven Schveighoffer Wrote: But still, what does it matter? Just don't use D1 if you want a compiler error, or don't try and trick the system into modifying ROM! There are plenty of projects using D1 that just don't do this, and they are fine. Implementing features to help people determine they created undefined behavior is simply a waste of time. If you feel you can fix it, by all means submit a patch, and it might get in. -Steve The point is that I didn't know the char array literal to be immutable. I thought it would be like any other array literal. Now I get to recheck my whole project to see whether I ever change an immutable array. Use D2 is not really an argument in this case as I didn't even know I was using a trick. For me it would have been great if the compiler would have segfaulted on this undefined behaviour.
Re: immutable string literal?
On Mon, 22 Feb 2010 11:24:36 -0500, strtr st...@spam.com wrote: Steven Schveighoffer Wrote: But still, what does it matter? Just don't use D1 if you want a compiler error, or don't try and trick the system into modifying ROM! There are plenty of projects using D1 that just don't do this, and they are fine. Implementing features to help people determine they created undefined behavior is simply a waste of time. If you feel you can fix it, by all means submit a patch, and it might get in. -Steve The point is that I didn't know the char array literal to be immutable. I thought it would be like any other array literal. Now I get to recheck my whole project to see whether I ever change an immutable array. Use D2 is not really an argument in this case as I didn't even know I was using a trick. For me it would have been great if the compiler would have segfaulted on this undefined behaviour. As I said before, it's not possible for the compiler to check this. It's unfortunate that array literals are treated differently than strings, and perhaps more unfortunate that Windows doesn't throw a loud error when this occurs. I don't see any way to fix that, because D1's spec is frozen. The crappy answer is, you'll just have to live with it. On the bright side, after frustratingly having to examine your code again for this problem, you are less likely to make this mistake in the future :) -Steve
immutable string literal?
On winXP (D1) I can compile/run this code without a problem.
Not even a warning.
void main() {
char[] s= immutable literal?;
s[$-1] = '!';
writefln(s);
}
Codepad runs into a segmentation fault.
http://codepad.org/NQfsRoR5
Why doesn't it result in a compiler error or warning?
If it did I would have noticed this quirk earlier.
Re: immutable string literal?
strtr wrote:
On winXP (D1) I can compile/run this code without a problem.
Not even a warning.
void main() {
char[] s= immutable literal?;
s[$-1] = '!';
writefln(s);
}
Codepad runs into a segmentation fault.
http://codepad.org/NQfsRoR5
Why doesn't it result in a compiler error or warning?
If it did I would have noticed this quirk earlier.
There's no compiler error because D1 doesn't have a const/immutable system.
There's no crash because Windows doesn't write-protect the data segment
which contains the literal.
