[haiku-bugs] Re: [Haiku] #7701: BMessage::FindString() behaves differently from BeOS's when field does not exist
- From: "axeld" <trac@xxxxxxxxxxxx>
- Date: Wed, 15 Jun 2011 20:59:01 -0000
#7701: BMessage::FindString() behaves differently from BeOS's when field does
not
exist
------------------------------------+----------------------------
Reporter: ttcoder | Owner: axeld
Type: bug | Status: new
Priority: normal | Milestone: R1
Component: Kits/Application Kit | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
------------------------------------+----------------------------
Old description:
> 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;
> }
>
> }}}
New description:
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;
}
}}}
--
Comment (by axeld):
Even though the BeOS semantics of BMessage::Find*() are really braindead,
it's still a compatibility issue that deserves to be fixed.
--
Ticket URL: <http://dev.haiku-os.org/ticket/7701#comment:3>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
