Bug 2544 – implicit const casting rules allow violations of const-safety

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.

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.

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

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

*** Issue 3621 has been marked as a duplicate of this issue. ***

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.

(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?

(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.

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.

(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 :)

Since when has this issue been Linux-specific?

I'm sorry about the last version change, I accidentally changed it thinking I was editing bug 3463 instead (I hate bugzilla for automatically moving to the next bug report when committing changes).

Seems to be a regression, since according to bug 2056, this code didn't compile in dmd 2.013.

As far as I can tell, all of these cases are fixed by my patch to 4251. It uses references as the highest indirection instead of arrays, but exposes the same bug. *** This issue has been marked as a duplicate of issue 4251 ***