[Issue 4021] [CTFE] AA rehash

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4021


Michael Rynn <y0uf00bar at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |y0uf00bar at gmail.com


--- Comment #1 from Michael Rynn <y0uf00bar at gmail.com> 2010-04-08 17:28:49 PDT ---
Regarding calls to _aaRehash(aaA* paa, TypeInfo keyti) from the .rehash
property.  The D 2.042 passes to aaRehash a  TypeInfo instance that is
inconsistent with other internal calls to it by _aaGet  .rehash passes the AA
typeinfo, while _aaGet passes the key TypeInfo.

    private char* cstr(string s)
    {
        char[] buf = new char[s.length+1];

        uint slen = s.length;
        for(int si = 0; si < slen; si++)
        {
            buf[si] = s[si];
        }
        buf[slen] = 0;
        return buf.ptr;
    }

void* _aaRehash(AA* paa, TypeInfo keyti)
{
    BB newb;
//**************** stick these lines in, and you will see what I mean.., and
might be motivated to fix it soon.

    TypeInfo origti = paa.a.keyti;
    if (origti != keyti)
    {
        printf("wrong ti - need %s, not %s\n", cstr(origti.toString()),
cstr(keyti.toString()));
    }
//****************

More explanation ad nauseum.

_aaGet calls _aaRehash with the keyti it got (which is really the TypeInfo of
the key), and caches it in struct BB. _d_assocarrayliteralT also figures out
and caches the key TypeInfo from the TypeInfo_AssociativeArray. 

_aaRehash is written so that it must use same key TypeInfo as aaGet, and
_d_assocarrayliteralT, in the keyti.compare, otherwise, keys may end up
differently ordered after a rehash, and subsequent searches may fail. I was
very puzzled when this happened when testing .rehash. This bug has been present
for some time now, so maybe .rehash is not frequently used.

When .rehash is called from D code, and _aaRehash is called with the TypeInfo
of the AA , presumed to be a TypeInfo_AssociativeArray, and not that of the
key.

This is just a bit more evidence that the AA C interface is old and rickety.

It could at least be made more consistent, and less dangerously redundent. 
_aaRehash should not need a TypeInfo passed to it at all.  It already has the
correct keyti in struct BB, if there has been any entries added.

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