http://d.puremagic.com/issues/show_bug.cgi?id=2544

           Summary: implicit const casting rules allow violations of const-
                    safety
           Product: D
           Version: 2.022
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: spec
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: lat7h@virginia.edu


The const system allows const views of mutable data; however, when used with enough levels of indirection, accidental mutable access of const data is also possible.

The smallest example I have found is

----
const(real)[] constants = [3.14159265358979323844L, 2.71828182845904523536L]; real[][][] unconsted = [[[]]];        // create mutable data const(real)[][][] unsafe = unconsted; // and a partially-constant view of it unsafe[0] = [constants];              // place const data in the const view unconsted[0][0][0] = 3.14L;           // simplify pi using the mutable view
----

This is obviously contrived, but several of these layers of indirection can be achieved (less succinctly but more commonly) using ref parameters to methods instead.

I think that it suffices to require most intermediate levels of const-ness to
be illegal; you can either have the original const-ness or a more-const formal
with at most (I think) 2 levels of mutable indirection remaining:
    const(T[])[][] assigned from T[][][] is OK,
    const(T)[][][] assigned from T[][][] is not OK.
I have not been able to prove two levels is safe, but I have also not been able
to construct a counterexample.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2544





------- Comment #1 from lat7h@virginia.edu  2009-01-01 20:31 -------
I included an unnecessary level of indirection before.  A simpler example:
----
const(int)[] answers = [42];       // create const data
int[][] unconsted = [[]];          // create mutable data
const(int)[][] unsafe = unconsted; // and a partially-constant view of it
unsafe[0] = answers;               // place const data in the const view
unconsted[0][0] = 43;              // change const data
----
Thus, while "const(T)[] = T[]" is safe, "const(T)[][] = T[][]" is not; only a
single level of implicit indirection in the cast preserves constness.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2544


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com




------- Comment #2 from smjg@iname.com  2009-01-02 06:56 -------
I've thought quite a bit about this and come up with what seems to be a solution, which also deals with another problem that's been around for years. I've posted it on the newsgroup, as it's rather long for here.

"Possible D2 solution to the upcasting array problem, and a related problem
with const and nested arrays"
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81566


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2544


maxmo@pochta.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




------- Comment #3 from maxmo@pochta.ru  2009-02-18 04:40 -------


*** This bug has been marked as a duplicate of 2095 ***


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2544


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #4 from Stewart Gordon <smjg@iname.com> 2009-12-17 03:34:15 PST ---
*** Issue 3621 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2544


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |schveiguy@yahoo.com
         Resolution|DUPLICATE                   |


--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> 2009-12-17 05:11:24 PST ---
I'm going to reopen this.  Although it is technically a subset of bug 2095, it is not a duplicate.  It is possible to fix this bug without fixing 2095.

It appears that a fix was inserted for 3621, repeated here for consistency:

http://www.dsource.org/projects/dmd/changeset/299

When the compiler is released with this fix, then this bug can be closed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2544



--- Comment #6 from Stewart Gordon <smjg@iname.com> 2009-12-17 05:19:13 PST ---
(In reply to comment #5)
> I'm going to reopen this.  Although it is technically a subset of bug 2095, it is not a duplicate.  It is possible to fix this bug without fixing 2095.
> 
> It appears that a fix was inserted for 3621, repeated here for consistency:
> 
> http://www.dsource.org/projects/dmd/changeset/299
> 
> When the compiler is released with this fix, then this bug can be closed.

Does this change cover all cases discussed in the thread linked to in comment 2?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2544



--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> 2009-12-17 05:31:50 PST ---
(In reply to comment #6)
> 
> Does this change cover all cases discussed in the thread linked to in comment 2?

From looking at the code changes, it does not fix casts from a derived class array to a base class array.  However, that issue is captured in bug 2095.  I don't think this means 2095 is not an important bug to fix, but it might be that this bug is *really* simple to fix, and 2095 is not (Walter would know better).  I'd rather have this part of it fixed than neither part fixed.

In any case, the example in comment 1 and the original description should theoretically be fixed by the change, so we can at least close *this* bug.  I agree that something needs to be done about casting a derived class array to a base class array, and it seems like the solution proposed in the thread would work.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2544



--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-03-16 20:19:39 PDT ---
It appears that the offending code still compiles in dmd 2.041.  I can't remember why I thought the given changeset should fix the problem, maybe it was fixed and then regressed.  In any case, it's still broken.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=2544



--- Comment #9 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-04-14 10:36:19 PDT ---
(In reply to comment #5)
> Although it is technically a subset of bug 2095
To be precise, it's theoretically a subset of 2095, but technically they are different :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------