www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2732] New: Setting new key for Associative Array of Static Array causes RangeError

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2732

           Summary: Setting new key for Associative Array of Static Array
                    causes RangeError
           Product: D
           Version: 2.025
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: accepts-invalid, rejects-valid
          Severity: normal
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: hskwk inter7.jp


string[2][string] hash;

// All assignment expressions listed below are compiled without any error nor
warning
// and throw runtime RangeError.
hash["key"] = ["a","b"]; 
hash["key"] = new string[2];
hash["key"] = null;
hash["key"] = "";
hash["key"] = [0,0]; 
hash["key"][0] = "";

assert(typeid(typeof(hash["key"])) == typeid(typeof(["a","b"])) );


On the other hand, Associative Array of Dynamic Array works well.

string[][string] hash;
hash["key"] = ["a", "b"];
writefln( hash["key"] ); 


occurs in both D1/D2.


-- 
Mar 13 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2732


unknown simplemachines.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |unknown simplemachines.org





Simplified test case:

int[1][int] hash = null;
int[1] v = [1];

//*(hash[0]) = 42;
hash[0] = v;

Uncomment the commented line, and it works.  It looks to me as if |hash[0] =
var;| isn't being treated as an initialization of the key, for some reason.

-[Unknown]


-- 
Mar 29 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2732








real[2][int] hash = null;
real[2] v = [3,4];

*(hash[0])=1;
write(hash[0]);
// -> [1 0], very strange result. where does 0 come from? *1

hash[0]=v;
write(hash[0]);
// -> [3 4], it works well if key have been already set.


*1
real.init is NaN. actually: write(new real[2]) -> [nan nan].
This test code might show us a different bug of accepts-invalid.

To make matters worse, following code is compiled without any error
and cause runtime object.Exception: lengths don't match for array copy.

real[1] v = [3,4];

I think that this code should be an compile-time error because
the compiler knows types of both `real[1] v' and `[3,4]'.
I will report these bugs if they have not been reported on this tracking
system.


-- 
Mar 30 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2732


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com
            Version|2.025                       |D1



This works in D2.053, but still throws a RangeError in D1.

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