[haiku-appserver] Re: BMessage AddData
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 13 Jul 2005 07:04:23 +0200 CEST
Korli <korli@xxxxxxxx> wrote:
> Axel Dörfler a écrit :
> >>I'm having problems with BMessage::AddData(), typically when used
> >>with a B_UINT8_TYPE and with a size.
> >Is it used in the same way in BeOS? To me, using B_UINT8_TYPE with a
> >size different of sizeof(uint8) looks wrong. And obviously, Eric
> > (who
> >wrote BMessage) thought in the same way.
> >Of course, maybe AddData() shouldn't care about this, but B_RAW_TYPE
> >looks more appropriate here.
> This code works on R5. This is a bad assumption.
Sure, it works on R5, but that does not mean it has been thought to
work this way. It may just do. IOW if you aren't bound to B_UINT8_TYPE
for compatibility, I would rather use B_RAW_TYPE here. OTOH (but this
is not mentioned in the BeBook), we could also explicetly allow to
store arrays of the number types, make sure they are unflattened
correctly even on another platform - and have it documented this way.
Since BeOS already seem to do it, that's probably the way to go.
> >>As I don't understand fully this code, could someone have a look at
> >>this method ? It doesn't handle every type codes the same way which
> >>is very weird.
> >It can't treat every type in the same way, as all types have a
> > special
> >handling, ie. number types need to be endian-aware, same for
> > entry_refs
> >but even more complicated.
> I'm not sure about this.
Yes, you were, and Ingo are, as always, right. Endian-awareness is only
needed for the unflattening case, BMessages are always stored in native
endian for efficiency.
> >>I didn't find unit tests for this method. Having one would also be
> >>great.
> >As every type adder uses this method, there are indirect unit tests
> > for
> >it - but that's obviously not enough :-)
> A bad functional assumption leads to incorrect tests :)
Definitely, that's why someone should write them who didn't write the
code to be tested :-)
> Input addons and input_server work as is on R5, that's the reason why
> I
> believe this implementation is wrong.
Obviously :-)
Bye,
Axel.
Other related posts:
