orogen should not create types that are ambigious to typelib about orogen HOT 4 CLOSED

.... You bad, bad person.

While I do agree with you on the principle, I really want to say this: SERIOUSLY ?

from orogen.

;-) Good Morning Sylvain.

This was again such as "bad things happen" event.
I know this seems ugly and of course it is, but it happened because i used this struct first:

 4 struct battery_data{
  5     unsigned state:8;
  6     unsigned cell_voltage0:16;
  7     unsigned cell_voltage1:16;
  8     unsigned cell_voltage2:16;
  9     unsigned cell_voltage3:16;
 10     unsigned cell_voltage4:16;
 11     unsigned cell_voltage5:16;
 12     unsigned cell_voltage6:16;
 13     unsigned cell_voltage7:16;
 14     unsigned temperature:16;
 15     unsigned error_state:8;
 16 } __attribute__ ((packed)) __attribute__((__may_alias__));

unfourtnalty orogen still accepts this structure, but typelib can not handle these bitfields correctly, so because of this "it has to work quickly" daily working ways is simply added a "C++ like header for the only serialization-used C header which has a simliar name. This resulted in this next orogen "bug".

... daily computer scientest work ...

P.S. i know i could had used uint8_t in this example, but the structure was different in early versions so i used bitfields...

from orogen.

Hm, in general, we got a problem with bitfields. In typelib all offsets are in byte. If you define a type using bitfields, were the members are not alligend to 8 bit, it will fail. The clang importer has a check for these.

from orogen.

This is solved by the new-style Types access (Types.BatteryData vs Types.battery_data). Closing.

from orogen.