patchCERTI - Patches: patch #6534, IEEE 1516.2 compliant encoding

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #6534: IEEE 1516.2 compliant encoding

Submitter:  Petr Gotthard <gotthardp>
Submitted:  Sun 08 Jun 2008 12:15:32 PM UTC
   
 
Category:  None Priority:  5 - Normal
Status:  Ready For Test Privacy:  Public
Assigned to:  gotthardp Open/Closed:  Closed

Jump to the original submission

Wed 29 Apr 2009 09:37:08 AM UTC, comment #9: 

This will be in CERTI 3.3.2

Eric NOULARD <erk>
Group administrator
Fri 06 Mar 2009 10:01:28 AM UTC, comment #8: 

libHLA with IEEE-1516 encoding is in mainstream CVS

Eric NOULARD <erk>
Group administrator
Mon 29 Sep 2008 09:11:20 PM UTC, comment #7: 

Just added libHLA to mainstream.
You may already do

make libHLA

in order to support libHLA-only install I'll try
to use CMake component (CMake 2.6 only)
and/or to add a global option which tells that you
only want to build libHLA.
The first solution only works for CMake 2.6 whereas
the second may be used for any CMake version.

Eric NOULARD <erk>
Group administrator
Mon 07 Jul 2008 10:04:51 AM UTC, comment #6: 

Eric,
creating a CERTI-independent library is a good idea. I will commit the 1516.2 work there as soon the directory/namespace issues are agreed.

I agree that the libhla should have an own namespace (libhla:: is fine) to avoid collisions with CERTI and other RTI.
It may be also useful to have a separate make target to build/install the libhla as CERTI might override "the other RTI".


Petr

Petr Gotthard <gotthardp>
Group Member
Mon 07 Jul 2008 09:40:20 AM UTC, comment #5: 

Hi Petr,

The code compiles and runs ok on my 64 bits config now.
What do you think of adding this to CERTI inside
a libHLA directory which would only contains RTI
agnostics classes which may be helpfull for a federate
using any RTI implementation (including CERTI)?

I'd like to set up such a libHLA library which may contains:

1) Your work on IEEE-1516 type encoding
2) The current "xxxClock" classes now in libCERTI
3) ?may be the MessageBuffer class" currently in libCERTI

The last 2 are autonomous source beside the fact that
they must be taken away from certi:: namespace.

We may setup a libhla:: namespace and put all this in there?

I will send a message on certi-devel for this proposal
this afternoon.
The idea is to build a portable "libHLA" library which would
be helpful for anyone writing a federate.

Eric NOULARD <erk>
Group administrator
Fri 27 Jun 2008 03:03:25 PM UTC, comment #4: 

I have fixed the 64bit issues. This version should work with x86 linux (both 32b and 64b) and x86 windows (32b).

The correct ./encod should print a list of numbers, without any error messages.

(file #15949)

Petr Gotthard <gotthardp>
Group Member
Wed 18 Jun 2008 08:13:49 PM UTC, comment #3: 

Nice evolution.
A fast try gives some compilation error (gcc 4.3.1)
which disappear if you add

#include <cstdlib>
#include <cstring>
in types1516.h

this is for malloc/realloc/memmove...

The execution of encod fails with the following message:
./encod
0000:  41 00 00 00 00 00 00 01 40 09 1e b8 51 eb 85 1f
0000:  00 00 00 00 30 00 00 00 00 00 00 2a 31
terminate called after throwing an instance of 'std::out_of_range'
  what():  HLAvariableArray: index out of range
Abandon

when compiling with debug (-g) I get:
./encod
0000:  41 00 00 00 00 00 00 01 40 09 1e b8 51 eb 85 1f
0000:  00 00 00 00 30 00 00 00 00 00 00 2a 31
test4: <output> does not match expected result
0000:  00 00 00 01 00 a9 7a 0d 40 09 1e b8 51 eb 85 1f

0000:  00 00 00 01 00 00 00 00 40 09 1e b8 51 eb 85 1f

terminate called after throwing an instance of 'std::runtime_error'
  what():  HLAbuffer: bad pointer
Abandon

Is this the expected outputs?

I've not checked but may be your code is not 64 bits clean?
(or gcc 4.3.1 produces buggy code???)
My current config is x86_64 linux, I'll try tomorrow on
a 32 bits linux box.

beside those to-be-confirmed preliminary bugs
the code now have features I like.


Eric NOULARD <erk>
Group administrator
Wed 18 Jun 2008 05:49:50 PM UTC, comment #2: 

Hello, here goes a second version of my encoding functions.
The second version:

  • does array range checking
  • does buffer overflow checking
  • allows user-supplied buffers (non-resizable)
  • allows automatic memory management (self-resizable buffers)
  • provides some bugfixes to previous version


It does not yet supports the assignment operator. Assigment of self-reallocating variable-sized structures isn't easy. ;-)


(file #15863, file #15864, file #15865)

Petr Gotthard <gotthardp>
Group Member
Wed 11 Jun 2008 10:51:52 AM UTC, comment #1: 

I did already comment on the patch on the ML:
http://lists.nongnu.org/archive/html/certi-devel/2008-06/msg00001.html

I re-affirm that the cast 'this' trick is buggy
but I did not find time to propose another solution.

In the meantime I advise you to use C++ style cast
and not C-style cast that is:

(Type *)(expr)
should replaced with either:

static_cast<Type*>(expr)
or
reinterpret_cast<Type*>(expr)

You may have a look at Nathan Myers book
"More Effective C++"
Item 2 is:"Prefer C++ Style Cast"
http://www.amazon.com/gp/reader/020163371X/ref=sib_dp_pt#reader-link


Eric NOULARD <erk>
Group administrator
Sun 08 Jun 2008 12:15:32 PM UTC, original submission:  

The most efficient and the most convenient way to manipulate IEEE 1516.2 data buffers I have found.

I will write a separate e-mail to the CERTI list...

Petr Gotthard <gotthardp>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #15949:  types1516-03.tar.gz added by gotthardp (6KiB - application/x-gzip - Third version.)
file #15863:  types1516.cpp added by gotthardp (2KiB - application/octet-stream - Second version.)
file #15864:  types1516.h added by gotthardp (21KiB - application/octet-stream - Second version.)
file #15865:  encod.cpp added by gotthardp (3KiB - application/octet-stream - Second version.)
file #15816:  types1516.h added by gotthardp (16KiB - text/plain - Initial implementation.)
file #15817:  encod.cpp added by gotthardp (2KiB - text/plain - Initial implementation.)

 

Depends on the following items: None found

Digest:
   task dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by erk (Posted a comment)
  • -email is unavailable- added by gotthardp (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-04-29 erk Open/ClosedOpen Closed
    2009-03-06 erk StatusIn Progress Ready For Test
    2008-07-15 erk Dependencies- task #8386 is dependent
    2008-07-07 erk StatusNone In Progress
        Assigned toNone gotthardp
    2008-06-27 gotthardp Attached File- Added types1516-03.tar.gz, #15949
    2008-06-18 gotthardp Attached File- Added types1516.cpp, #15863
        Attached File- Added types1516.h, #15864
        Attached File- Added encod.cpp, #15865
    2008-06-08 gotthardp Attached File- Added types1516.h, #15816
        Attached File- Added encod.cpp, #15817

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code