[Issue 10201] "= void" initialization should not be allowed in @safe

2016-06-07 Thread via Digitalmars-d-bugs
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

2016-06-07 Thread via Digitalmars-d-bugs
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

2016-06-07 Thread via Digitalmars-d-bugs
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

2016-06-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10201

Walter Bright  changed:

   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

2016-06-07 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=10201

Walter Bright  changed:

   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

2013-11-21 Thread d-bugmail
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

2013-07-26 Thread d-bugmail
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

2013-05-29 Thread d-bugmail
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: ---