The program exits abnormally when using the @optional or @external annotations

[Orbuild]

• When I use the code from the master branch, I ran a simple publish-subscribe program, where the message format is as follows:

module MyTestData
{ 
  struct Msg
  {
    long id;
    @optional char flag;
    string message;
  };
};

• Before the message is sent, the flag field is tampered with as a character type. At this point, running the program results in an error as follows:

  MyTestData_Msg msg;
  ...
  msg.flag = 'A';

  === [MyTestPublisher]  Waiting for a reader to be discovered ...
  [MyTestPublisher]  Writing : Message (id: 1)
  Segmentation fault (core dumped)

• When the flag field is decorated with @external, the same error occurs. According to the official documentation, when the flag field is decorated with @optional or @external, and when the flag is set to a string type, the program runs normally. However, when the flag field is set to a character type, the program exits abnormally without checking the type of the flag field or providing any error message. Is this a bug, and should type checking be performed on variables decorated with @optional or @external? It might be more user-friendly to provide relevant error messages when type checking fails. Looking forward to your response!

[eboasson]

I'm surprised that even compiles without dire warnings from the C compiler: @optional and @external result in a struct containing a pointer to the data rather than the data itself and you're assigning a character constant to it.

Your example results in the following C type definition:

typedef struct MyTestData_Msg
{
  int32_t id;
  char * flag;
  char * message;
} MyTestData_Msg;

During serialisation, that flag field gets checked for a null pointer (if so, the optional field is not present) and if not gets dereferenced to serialise the contents. If you assign 'A' to flag, it tries to dereference at address 0x41 as it is required to do. A crash is totally reasonable then.

In other words, what you're running is a minor misunderstanding of how @optional is mapped in C. The crash you see is very nearly unavoidable and is not a lack of type checking.