orogen should not create types that are ambigious to typelib

[goldhoorn]

I had a header which contains this structures:

struct battery_data{
...
};
struct BatteryData{
...
};

In geeneral this works fine but later by using them in the typelib binding i hade no way to handle them anymore caused by this error:

10:10:58.644 (Roby) there is a type registered at Types::BatteryData that differs from the one we are trying to register
10:10:58.644 (Roby) registered type is
10:10:58.644 (Roby)   /BatteryData {
10:10:58.644 (Roby)     state </uint32_t>,
10:10:58.644 (Roby)     cell_voltage </uint32_t[8]>,
10:10:58.644 (Roby)     temperature </uint32_t>,
10:10:58.644 (Roby)     error_state </uint32_t>}
10:10:58.644 (Roby) new type is
10:10:58.644 (Roby)   /battery_data {
10:10:58.644 (Roby)     state </uint32_t>,
10:10:58.644 (Roby)     cell_voltage0 </uint32_t>,
10:10:58.644 (Roby)     cell_voltage1 </uint32_t>,
10:10:58.644 (Roby)     cell_voltage2 </uint32_t>,
10:10:58.644 (Roby)     cell_voltage3 </uint32_t>,
10:10:58.644 (Roby)     cell_voltage4 </uint32_t>,
10:10:58.644 (Roby)     cell_voltage5 </uint32_t>,
10:10:58.644 (Roby)     cell_voltage6 </uint32_t>,
10:10:58.644 (Roby)     cell_voltage7 </uint32_t>,
10:10:58.644 (Roby)     temperature </uint32_t>,
10:10:58.644 (Roby)     error_state </uint32_t>}

I put this issue to orogen because i see no way to handle this problem in the typelib binding, therefore i recomment that orogen should refuse the creation of such types then.

[doudou]

.... You bad, bad person.

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

[goldhoorn]

;-) 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...

[jmachowinski]

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.

[doudou]

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