Jump to page: 1 2 3
Thread overview
[Issue 4251] New: const(T) is appendable to const(T)[]
May 30, 2010
Pelle Månsson
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
Jul 13, 2010
nfxjfg@gmail.com
Jun 12, 2011
yebblies
Jun 16, 2011
yebblies
Jun 16, 2011
Stewart Gordon
Jun 16, 2011
yebblies
Jun 16, 2011
yebblies
Jun 16, 2011
Stewart Gordon
Jun 16, 2011
Stewart Gordon
Jun 17, 2011
yebblies
Jun 22, 2011
yebblies
Aug 04, 2011
Brad Roberts
Aug 04, 2011
yebblies
[Issue 4251] Hole in the type system: Base type reference can be assigned to subtype reference (Super* is treated as a supertype of Sub*)
Nov 17, 2011
timon.gehr@gmx.ch
[Issue 4251] Hole in the const system: immutable values can be overwritten (const(T) is appendable to const(T)[])
[Issue 4251] Hole in the const system: immutable(T)[] implicitly casts to ref const(T)[]
Dec 13, 2011
Kenji Hara
Jan 16, 2012
Walter Bright
May 30, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4251

           Summary: const(T) is appendable to const(T)[]
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: pelle.mansson@gmail.com


--- Comment #0 from Pelle Månsson <pelle.mansson@gmail.com> 2010-05-30 04:11:17 PDT ---
void messwith(T)(ref const(T)[] ts, const(T) t) {
    ts ~= t;
}

class C {
    int x;
    this(int i) { x = i; }
}

void main(string[] args) {

    C[] cs;
    immutable C ci = new immutable(C)(6);

    assert (ci.x == 6);

    messwith(cs,ci);

    cs[$-1].x = 14;

    assert (ci.x == 14); //whoops.
}

I'm pretty sure you shouldn't be able to do that.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 13, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4251


nfxjfg@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nfxjfg@gmail.com
            Summary|const(T) is appendable to   |Hole in the const system:
                   |const(T)[]                  |immutable values can be
                   |                            |overwritten (const(T) is
                   |                            |appendable to const(T)[])
           Severity|major                       |blocker


--- Comment #1 from nfxjfg@gmail.com 2010-07-13 10:57:33 PDT ---
Isn't this a really really really bad bug in the language specification?

Obviously you shouldn't be able to overwrite immutable values (unless you use
unsafe tricks).

What can be done to fix this hole in the const system?

Just disallowing appending const(T) to const(T)[] isn't really an option, is
it?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 13, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4251


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-07-13 11:54:33 PDT ---
The issue is casting a ref T[] to a ref const(T)[].

The safety is broken if you implicitly apply const two references deep.

I think this is a dup of bug 2095 (which actually is dup of a sub-1000 bug). But I think the const implications are somewhat new.  I recall there was either a discussion on the NG or another bug that covers this.  Maybe someone else can find it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 12, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4251


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, patch
                 CC|                            |yebblies@gmail.com


--- Comment #3 from yebblies <yebblies@gmail.com> 2011-06-12 08:14:13 PDT ---
https://github.com/D-Programming-Language/dmd/pull/115

When implicitly converting types with indirections, only allow the following results:
> completely mutable
> completely non-mutable
> exactly one mutable indirection
> the same number of mutable indirections as before

eg.
> T*** => const(T***)   allowed, full const
> T*** => const(T**)*   allowed, tail const
> T*** => const(T*)**   not allowed
> T*** => const(T)***   not allowed
> T*** => T***          allowed, same number of mutable indirections
> immutable(T*)** => const(T*)** allowed, same number of mutable indirections
etc

This prevents (as far as I know) using implicit conversions to let a pointer to mutable and a pointer to immutable point to the same place using const conversions.

eg.
int** a = [new int].ptr;
const(int)*** b = &a;
*b = [new immutable(int)].ptr;

The same applies to other reference types.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4251


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lat7h@virginia.edu


--- Comment #4 from yebblies <yebblies@gmail.com> 2011-06-15 20:22:49 PDT ---
*** Issue 2544 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: -------
June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4251


Stewart Gordon <smjg@iname.com> changed:

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


--- Comment #5 from Stewart Gordon <smjg@iname.com> 2011-06-16 01:22:22 PDT ---
(In reply to comment #3)
>> T*** => const(T***)   allowed, full const
>> T*** => const(T**)*   allowed, tail const
>> T*** => const(T*)**   not allowed
>> T*** => const(T)***   not allowed
>> T*** => T***          allowed, same number of mutable indirections
>> immutable(T*)** => const(T*)** allowed, same number of mutable indirections
>etc

I agree about the first five of these.  But I'm not sure if this last one is safe.  I'll think about it when I've more time.  In any case, see this set of rules I proposed before:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81566

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4251



--- Comment #6 from yebblies <yebblies@gmail.com> 2011-06-16 01:41:07 PDT ---
(In reply to comment #5)
> I agree about the first five of these.  But I'm not sure if this last one is safe.  I'll think about it when I've more time.  In any case, see this set of rules I proposed before:
> 
I haven't been able to think of a way to break it, but that doesn't mean there isn't one!

> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=81566

I did find this today.  As far as I can tell, this fix combined with the fix for issue 2095 fixes it all.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4251



--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-06-16 08:06:02 PDT ---
I think the cases are all sound.

In order for there to be a problem, both mutable and immutable data need to be castable into const.  If you cannot cast mutable into const N references deep, then you can't accidentally rebind it to immutable data.

This all stems from being able to treat mutable data as const, and also as mutable at the same time.  Being able to treat immutable data as const and immutable at the same time does not cause any harm.

This is definitely one of those things that makes my brain hurt... It's like 4 dimensional geometry :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4251



--- Comment #8 from yebblies <yebblies@gmail.com> 2011-06-16 08:14:06 PDT ---
(In reply to comment #7)
> This is definitely one of those things that makes my brain hurt... It's like 4 dimensional geometry :)

I had to draw out tables and diagrams before I could get this right in my mind.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 16, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=4251



--- Comment #9 from Stewart Gordon <smjg@iname.com> 2011-06-16 12:12:23 PDT ---
(In reply to comment #5)
>>> immutable(T*)** => const(T*)** allowed, same number of mutable indirections

As it turns out, this is unsafe, as the following code shows:

----------
import std.stdio;

void main() {
    immutable(int) i = 42;
    immutable(int)* ip = &i;
    immutable(int)** ipp = &ip;
    const(int)** cpp = ipp;

    int m = 69;
    // the next statement makes ip point to a mutable value!
    *cpp = &m;

    writefln("%d", *ip);
    m = 105;
    writefln("%d", *ip);
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
« First   ‹ Prev
1 2 3