[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [certi-dev] Problem with VariableLengthData

From: Christoph Laesche
Subject: Re: [certi-dev] Problem with VariableLengthData
Date: Fri, 17 Jun 2011 13:35:33 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110326 Lightning/1.0b3pre Thunderbird/3.1.9

I have fixed this issue and attached a patch (for CERTI 3.4.0). I've
tested it with Linux (gcc 4.3.2) and Windows (Visual C++ Express 2005).

On 06/16/2011 07:02 PM, Eric Noulard wrote:
> 2011/6/16 Christoph Laesche <address@hidden>:
>> Hi,
>> I am using several own datatypes which I serialize to a
>> VariableLengthData object to transfer it using CERTI (w/ rti1516). I
>> noticed that the transfered data does not arrive correctly. The
>> VariableLengthData object which I receive in the other federate does not
>> have the correct size.
>> I tracked down the problem and found out that it occurs when the data
>> contains a byte of the value 0. It seems as if the problem is the usage
>> of string as ParameterValue_t because the .size() call will return the
>> string length and therefore will take a 0 byte as an \0, thus ending the
>> string (although there is data behind it).
> Pretty right we should have something like:
> typedef std::vector<char> ParameterValue_t;
> (this has to be done for AttributeValue_t as well)
> unfortunately doing this unique change in certi.hh
> currently leads to multiple compile errors just now.
> This is fixable but this require some work inside the message
> management of CERTI
> because generated files ([N]M_Classes.[hh|cc]) assumes AttributeValue_t
> and ParameterValue_t are string.
>> Is this a known problem and is there a fix for it?
> I guess the string usage is a bad historical habit,
> and we all just have been lucky because we did not face this issue [yet]
> so basically this is not a known issue :-(.
>> How have you serialized your data objects without having a 0 in it?
> We don't do anything special, but may be the HLA 1.3 interface does not
> exhibit the same issue and we currenlty use it more than the 1516 one.
> I guess you may be blocked with this issue.
> Are you willing to provide a patch that works for you?

Attachment: string_to_vector.patch
Description: Text document

reply via email to

[Prev in Thread] Current Thread [Next in Thread]