BMessage::FindString() behaves differently from BeOS's when field does not exist

[ttcoder]

m.FindString("myfield", &s) will leave 's' untouched if "myfield" is not part of 'm'. Expected behavior: in addition to returning an error code, it should also reset the string, much like m.FindInt32( "myfield", &i ) reset i to zero.

Looking at the BeBook I see it does not lean much one way or the other, so I'm tentatively categorizing this as a 'bug' only insofar as it differs from the BeOS behavior I've relied on in the past: the behavior under Haiku breaks my app (though the workaround is straight-forward). Under BeOS I could do this:

int main()
{
    BMessage m;
    m.AddString( "one", "value" );

    BString s;

    m.FindString( "one", &s );
    puts( s.String() );
    m.FindString( "two", &s );
    puts( s.String() );
}

and correctly get a blank output at the second puts() due to the absent field.

In case this sticks, here's a possible one-liner 'patch': in Message.cpp line 2635:

           const char *cstr = NULL;
	    status_t error = FindString(name, index, &cstr);
	    if (error < B_OK)
	    {
	        string->Truncate(0);  // <-- here it is, a reset that's fairly fast (Truncate() in "lazy" mode)
	        return error;
	    }
	

[anevilyak]

You do realize FindString returns an error code if the field couldn't be found, yes?

if (m.FindString("one", &s) == B_OK) 
  puts(s.String());

Will work fine and does not depend on side effects that aren't guaranteed or documented.

[ttcoder]

Replying to anevilyak:

and does not depend on side effects that aren't guaranteed or documented.

Ok roger that, I can live with Haiku's FindString() remaining as it is. The BeOS implementation makes more sense to me (consistency of behavior between FindInt32() and FindString(), and above all, allowing client code to be more simple and elegant) but not too many devs rely on this 'feature' of BMessage like I do, I suppose.

[axeld]

Even though the BeOS semantics of BMessage::Find*() are really braindead, it's still a compatibility issue that deserves to be fixed.

[axeld]

Fixed in hrev42200, thanks for the report.