[Issue 10201] "= void" initialization should not be allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=10201 --- Comment #8 from Walter Bright--- (In reply to Dicebot from comment #6) > There is no array bounds checking in that example as `arr.ptr` syntax is > used. You're right. But it's marked @trusted anyway, which defeats @safe checking, because pointer indexing is not allowed in @safe code. --
[Issue 10201] "= void" initialization should not be allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=10201 --- Comment #7 from Dicebot--- I do agree with closing it for now though, as the issue is unlikely to cause any trouble in real code and thus is not worth major attention. --
[Issue 10201] "= void" initialization should not be allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=10201 --- Comment #6 from Dicebot--- (In reply to Walter Bright from comment #4) > (In reply to monarchdodra from comment #2) > > I mentioned this in > > https://github.com/D-Programming-Language/phobos/pull/1434#issuecomment- > > 21644766 with the example: > > The example is still @safe because the array bounds checking will not allow > an out of bounds index. There is no array bounds checking in that example as `arr.ptr` syntax is used. --
[Issue 10201] "= void" initialization should not be allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=10201 Walter Brightchanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Walter Bright --- I'm going to mark this as "wontfix" because it is not the charter of @safe to guarantee ints have a predictable value. The charter is memory safety. Trying to heap other things into it is a never-ending thing because there's no definition for it. --
[Issue 10201] "= void" initialization should not be allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=10201 Walter Brightchanged: What|Removed |Added Keywords||safe CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright --- (In reply to monarchdodra from comment #2) > I mentioned this in > https://github.com/D-Programming-Language/phobos/pull/1434#issuecomment- > 21644766 with the example: The example is still @safe because the array bounds checking will not allow an out of bounds index. --
[Issue 10201] = void initialization should not be allowed in @safe
https://d.puremagic.com/issues/show_bug.cgi?id=10201 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Severity|normal |enhancement --- Comment #3 from yebblies yebbl...@gmail.com 2013-11-22 02:27:23 EST --- As noted in the github discussion, this is working as designed. Unless you can break memory safety without using @system features, it's an enhancement. http://forum.dlang.org/post/ko5d7a$abj$1...@digitalmars.com -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10201] = void initialization should not be allowed in @safe
http://d.puremagic.com/issues/show_bug.cgi?id=10201 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com 2013-07-26 13:05:21 PDT --- (In reply to comment #1) So it is not that dangerous in that sense, but can be used to workaround some guarantees provided by disabled constructor. Prohibiting all void initalizers in @safe may be both more simple and consistent. It is dangerous in the sense that for a struct that is not POD, you are violating its internal integrity, at which point, it has no way to guarantee the safety of its own internal operations. I mentioned this in https://github.com/D-Programming-Language/phobos/pull/1434#issuecomment-21644766 with the example: // struct S { private size_t index; private ubyte[1] arr; ref ubyte get() @trusted { return arr.ptr[index]; } } void main() @safe { S s = void; ubyte a = s.get(); } // -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10201] = void initialization should not be allowed in @safe
http://d.puremagic.com/issues/show_bug.cgi?id=10201 --- Comment #1 from Dicebot m.stras...@gmail.com 2013-05-29 08:42:06 PDT --- Additional explanation - it does report an error if initialized value is a pointer or contains a pointer. It does not report an error if value has disabled constructor though. So it is not that dangerous in that sense, but can be used to workaround some guarantees provided by disabled constructor. Prohibiting all void initalizers in @safe may be both more simple and consistent. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---