Policy for return by reference values in error cases

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Mar 23 17:30:08 UTC 2021


Hello,

for the RTEMS pre-qualification project I review currently most parts of 
the Classic API. It seems we have an unwritten rule that directives 
should not write to variables referenced by directive parameters if an 
error occurs. Examples:

* rtems_task_mode(previous_mode)

* rtems_task_set_priority(previous_priority)

* rtems_message_queue_receive(message_size)

* rtems_event_receive(received_events)

We should think about changing this rule to instead return "safe" values 
in error conditions. For example, lets have an application bug I 
encountered this year. The code originally looked like this:

#define APP_TIMEOUT RTEMS_NO_TIMEOUT

rtems_event_set events;

(void) rtems_event_receive(

     RTEMS_ALL_EVENTS,
     RTEMS_EVENT_ANY | RTEMS_WAIT,
     APP_TIMEOUT,
     &events
   );

if (event & X) != 0) {

...

}

Ok, you should check the return value, but ...

Something didn't go well and someone changed APP_TIMEOUT:

#define APP_TIMEOUT 1000

Now, sometimes the rtems_event_receive() timed out and the application 
worked with events produced by the stack frame and not 
rtems_event_receive(). In the case of rtems_message_queue_receive() it 
would be the message size.

In order to let broken applications fail a bit more gracefully, it would 
help to set the events and the message size to zero if the directive 
returns with an error. The modes could be set to the defaults, the 
priority to some invalid value, etc.

What do you think?

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/



More information about the devel mailing list