Thread overview
[Issue 7008] New: Associative array ABI is under-specified
Nov 25, 2011
Jerry Quinn
Nov 26, 2011
dawg@dawgfoto.de
Nov 27, 2011
Walter Bright
Dec 12, 2011
Jerry Quinn
November 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=7008

           Summary: Associative array ABI is under-specified
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: websites
        AssignedTo: nobody@puremagic.com
        ReportedBy: jlquinn@optonline.net


--- Comment #0 from Jerry Quinn <jlquinn@optonline.net> 2011-11-25 14:25:09 PST ---
The current ABI describes associative arrays as an opaque type.
However, for a debugger to work with them, it must understand the
structure.  For 2 compilers to be able to generate compatible code, they must
agree on the structure.  Currently the ABI specifies an AA as an opaque
implementation-defined type.

This means that multiple compilers will not be able to guarantee compatibility since the AA ABI is not specified.  Also, debuggers must refer to the source code of the compiler druntime in order to know how to work with the contents of an AA.

Specifying C functions to manipulate the opaque pointer solves the debugger issue, but not the issue of ensuring compatibility across compilers.

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


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg@dawgfoto.de


--- Comment #1 from dawg@dawgfoto.de 2011-11-26 15:13:37 PST ---
The functions are only partly helpful for a debugger.

IMHO we should switch completely to using
AssociativeArray from object.
The current situation of using it only in
certain cases is messy.

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


Walter Bright <bugzilla@digitalmars.com> changed:

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


--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> 2011-11-26 20:48:29 PST ---
Being an opaque pointer means that the implementation of associative arrays is entirely up to the runtime, not the compiler. The compiler should emit no dependencies on how it is implemented.

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



--- Comment #3 from Jerry Quinn <jlquinn@optonline.net> 2011-12-11 21:32:49 PST ---
(In reply to comment #2)
> Being an opaque pointer means that the implementation of associative arrays is entirely up to the runtime, not the compiler. The compiler should emit no dependencies on how it is implemented.

To make this work, the compiler has to have a documented interface to the AA. I feel we need a documented set of calls that will be output by the compiler, just as $ is documented as being translated to length.

At the moment, the only documentation is "read this file in druntime".  It's not a guarantee of how the compiler-AA interface works.  Without the guarantee another compiler cannot safely generate compatible code, and debuggers can't be guaranteed to know how to look at the contents of the AA.

Am I missing something in this request?

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