Bug 12980 – Undefined behavior: Assignment of static string to dynamic string

import std.stdio; char[10] getSomeString() { char[10] result; int i = 0; for (char a = '0'; a <= '9'; ++a) { result[i++] = a; } return result; } class A { this() { m = getSomeString(); } string m; } void main() { A a = new A(); writeln("STRING: ", a.m); // At this point a.m points to somewhere in stack and thus contains invalid value. }

(In reply to Yuriy from comment #0) > char[10] getSomeString() > { > char[10] result; > int i = 0; > for (char a = '0'; a <= '9'; ++a) > { > result[i++] = a; > } > return result; > } D is not fully memory-safe. A starting point to avoid such troubles is to require a [] at that return point: } return result[]; }

This code is perfectly legal. It just isn't safe. And if @safe were properly implemented with regards to slicing static arrays, and you marked your code here with @safe, then the compiler would generate an error when the static array was sliced. Unfortunately however, slicing static arrays is currently a hole in @safe: https://issues.dlang.org/show_bug.cgi?id=8838 But regardless, there's no bug in the language in your example, just in your code. It's not marked with @safe, so it's @system, so even if bug# 8838 were fixed, your code would still compile, because @system code is not checked for memory safety, and it's perfectly possible to do unsafe things with memory in @system code.

Ah, ok. Initially the bug was found when using std.digest.toHexString instead of getSomeString in my example. So should we add a @safe to toHexString and then wait for 8838 fix?

(In reply to Yuriy from comment #3) > Ah, ok. Initially the bug was found when using std.digest.toHexString > instead of getSomeString in my example. Yes toHexString returns an array by value. This is not common in D APIs. As more and more D code returns small arrays by value (to allow them to be @nogc and increase performance), this kind of problems and bugs will become sufficiently common that D programmers will be more aware of them and so they will avoid them... :-)