www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9498] New: Rang violation using AA

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

           Summary: Rang violation using AA
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: timvol ymail.com



The following worked in DMD 2.060 (and previous versions):

string[string] myValues;

ref string getValue(string v) {
   return myValues[v];
}

void main() {
   getValue("myValue") = "myString";
}

But in 2.061 it throws a range violation.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 12 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com
           Platform|x86_64                      |All
         OS/Version|Linux                       |All
           Severity|normal                      |regression


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498


Maxim Fomin <maxim maxim-fomin.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxim maxim-fomin.ru



---
This is neither a bug nor a regression. 

An element is accessed in return statement, which makes it an rvalue, so
allocation if absence does not applies here. 

It works as clarified in TDPL. From TDPL (p. 115):

"To read a value off an associative array given a key, just read aa [ key] .
(The compiler distinguishes reads from writes and invokes slightly different
functions.)" - it is implemented in druntime as aaGetValueX and aaGetRvalueX or
something like that.

Further: 

"If you try to read the value for a key not found in the associative array, a
range violation exception is thrown."

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |INVALID


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |yebblies gmail.com
         Resolution|INVALID                     |



Note the ref return from getValue, which makes 'myValues[v]' an lvalue.  It
could still be invalid, but not for the reasons stated.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498




---


 Note the ref return from getValue, which makes 'myValues[v]' an lvalue.  It
 could still be invalid, but not for the reasons stated.


This is irrelevant. The fact that function returns by ref indicates that value
should not be copied but returned by ref. If "myValue" was present that would
mean that pointer to the string is returned. Irrespective of how value is
returned, myValues[v] is invalid value here.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498








 Note the ref return from getValue, which makes 'myValues[v]' an lvalue.  It
 could still be invalid, but not for the reasons stated.


 
 This is irrelevant. The fact that function returns by ref indicates that value
 should not be copied but returned by ref. If "myValue" was present that would
 mean that pointer to the string is returned. Irrespective of how value is
 returned, myValues[v] is invalid value here.


This code works because indexing an AA with a key that does not exist is valid
in an lvalue context:

int[string] aa;
aa["asd"] += 2;

The following code also indexes an AA with a missing key in an lvalue context:

int[string] aa;
ref int get() { return aa["asd"]; }
get() += 2;

The assumption here is that indexing an AA with a non-existing key in a context
where an lvalue is expected does not result in a range violation.

Do you know of any reason why this is an incorrect assumption?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498




---


 This code works because indexing an AA with a key that does not exist is valid
 in an lvalue context:
 
 int[string] aa;
 aa["asd"] += 2;
 
 The following code also indexes an AA with a missing key in an lvalue context:
 
 int[string] aa;
 ref int get() { return aa["asd"]; }
 get() += 2;
 
 The assumption here is that indexing an AA with a non-existing key in a context
 where an lvalue is expected does not result in a range violation.
 
 Do you know of any reason why this is an incorrect assumption?


Actually D does not have notion of lvalue context - TDPL says about read and
write operations. According to it, returning from function is a read operation.

And function refness does not guarantee that original lvalue will be modified.
The use case could be:

int a = get(); 

which means refness is wiped out and operation is effectively a read operation.
Situation could be follows:

ref int foo() { return aa["asd"]; }
int bar() { return aa["asd"]; }

not only this is confusing and inconsistent, but it defeats the purpose of
having aaGetRvalueX - anyone who want allocation would be just putting ref to
function declaration to make things works.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498






 
 Actually D does not have notion of lvalue context - TDPL says about read and
 write operations. According to it, returning from function is a read operation.
 


TDPL does not completely define the language.  Unfortunately neither does the
spec, it is defined through a combination of TDPL, the spec, and DMD.  When
these disagree none are a definitive source.

The compiler most certainly has a notion of lvalue context for index
expressions.


 And function refness does not guarantee that original lvalue will be modified.
 The use case could be:
 
 int a = get(); 
 
 which means refness is wiped out and operation is effectively a read operation.
 Situation could be follows:
 
 ref int foo() { return aa["asd"]; }
 int bar() { return aa["asd"]; }
 
 not only this is confusing and inconsistent, but it defeats the purpose of
 having aaGetRvalueX - anyone who want allocation would be just putting ref to
 function declaration to make things works.


I'm not sure how any of this is relevant.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498




---


 And function refness does not guarantee that original lvalue will be modified.
 The use case could be:
 
 int a = get(); 
 
 which means refness is wiped out and operation is effectively a read operation.
 Situation could be follows:
 
 ref int foo() { return aa["asd"]; }
 int bar() { return aa["asd"]; }
 
 not only this is confusing and inconsistent, but it defeats the purpose of
 having aaGetRvalueX - anyone who want allocation would be just putting ref to
 function declaration to make things works.


 
 I'm not sure how any of this is relevant.


Than you should read again if you don't see the relevance. Function returning
AA value as discussed here is a case which should throw according to TDPL (spec
is silent unfortunately) and current D implementation in case of non-ref
functions. Presence of ref attribute does not matter because function performs
read operation in the first place. How value is returned (by ref or not) is of
secondary importance.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498






 Than you should read again if you don't see the relevance. Function returning
 AA value as discussed here is a case which should throw according to TDPL (spec
 is silent unfortunately) and current D implementation in case of non-ref
 functions. Presence of ref attribute does not matter because function performs
 read operation in the first place. How value is returned (by ref or not) is of
 secondary importance.


TDPL is not an authoritative specification, so the fact this is in line with
the way TDPL presents AAs does not conclusively prove this is correct behavior.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9498


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID



The old behavior was wrong-code bug, and fixed in 2.061.

Introduced commit/codeline:
https://github.com/D-Programming-Language/dmd/commit/9553d0c66337b477375cb77743defcdd79b8064d#L4L3995

AA indexing + assign syntax is a special form in D. If the acquired payload
from AA is _immediately_ set by assignment, it is treated as an insertion for
non-existing key and won't throw RangeError. Otherwise, AA indexing should be
always treated as a read of existing key - even if it is on Lvalue-context.

I'd like to show more specific example.

struct S { int value = 42; }

S[string] myValues;

ref S getValue(string v) {
   return myValues[v];
}

void main() {
    import std.stdio;
    writeln(getValue("myValue").value); // what will be displayed?
}

In 2.060 and earlier, myValues[v] had returned a reference to *uninitialized*
memory. From 2.061, it correctly throws RangeError. That's  safe behavior.

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