Policy for return by reference values in error cases

[Joel Sherrill]

On Tue, Mar 23, 2021, 12:30 PM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> 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?
>

My first thought is that I don't like covering up for applications that do
the wrong thing.

I'm overall rather ambiguous. It is possible that setting the value at the
top of the function could lead to overridden before used issues with
warnings and static analysis. I don't want to see every error case assign a
value to an output parameter though.

--joel


> --
> 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/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210323/5995a70f/attachment.html>