Strange issue when using AnsiString as key in map

Question

I have a map

map<AnsiString, Foo*>

When I try to look up values in the map I use a string I have received from a TMemoryStream and send it to a Foo* GetFoo(AnsiString) function that in turn creates an iterator and returns the object found. This works fine in most of the cases but in ONE function it doesn't return a value.

If I do FooID = FooID.SetLength(FooID.Length() - 1); where FooID is the AnsiString to use for the look up it works and returns the correct result. I was thinking that there might be some garbage in the stream but when I look at the AnsiStrings used in the place that works out of the box and the place that needs the hack they are identical!?

This is according to the IDE's debug value inspector... So there might be som trickery going on there. But what in earth could be causing this???

Update:

I found the implementation of the operator>>used.

PACKAGE TStream & operator >>(TStream &Stream, AnsiString &s)
{
    int i;

    Stream.ReadBuffer(&i, sizeof(i));
    if (i<0)
    {
        WideString ws;

        i=-i;
        ws.SetLength(i);
        if (i>0)
            Stream.ReadBuffer(ws.c_bstr(), i*sizeof(wchar_t));

        s=ws;

    } else if (i>0)
    {
        s.SetLength(i);
        Stream.ReadBuffer(s.c_str(), i);

    } else
        s="";

    return Stream;
}

Stepping through it seems to handle the received strings correctly. But I seem to recall hearing that issues with WideString is not uncommon :P

Update 2: I actually found an instance where the string returned is 6 chars long plus the ending \0 but the size is set to 7. So I guess my solution will be in the application sending that string since it supplies the wrong size.

score 0 · Accepted Answer · answered Jan 16 '13 at 05:48

0

They are obviously not identical, since you need to truncate an extra char to make it work correctly. So find out what that extra char actually is. Either the stream data has garbage in it to begin with, or the code that is reading the AnsiString from the stream has a logic bug in it that is introducing garbage.

When you use the debug inspector, make sure you are taking the AnsiString's entire length into account. By default, the inspector treats an AnsiString as a null terminated string and thus stops displaying data when it encounters the first null character it finds, so you might need to use the inspector's "Range" option to see everything that is actually present in the AnsiString's memory.

answered Jan 16 '13 at 05:48

Remy Lebeau

555,201
31
458
770

Obviously ;)... The code that reads the `AnsiString` is basically `TMemoryStream* data; AnsiString foo; *data >> foo`, same as in the places that work. – inquam Jan 16 '13 at 07:21
Yea, the issue was stuff intentionally added to one specific string from the sending application that caused the `Length` to be incorrect. – inquam Jan 16 '13 at 09:23
`*data >> foo` how does that even compile? Neither `TMemoryStream` nor `AnsiString` define a `>>` operator that reads a string from a stream. Did you implement your own custom operator? – Remy Lebeau Jan 16 '13 at 17:05
As you can see above I did find a custom implementation of that yes. – inquam Jan 17 '13 at 06:54

Strange issue when using AnsiString as key in map

1 Answers1