<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021, 12:30 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
for the RTEMS pre-qualification project I review currently most parts of <br>
the Classic API. It seems we have an unwritten rule that directives <br>
should not write to variables referenced by directive parameters if an <br>
error occurs. Examples:<br>
<br>
* rtems_task_mode(previous_mode)<br>
<br>
* rtems_task_set_priority(previous_priority)<br>
<br>
* rtems_message_queue_receive(message_size)<br>
<br>
* rtems_event_receive(received_events)<br>
<br>
We should think about changing this rule to instead return "safe" values <br>
in error conditions. For example, lets have an application bug I <br>
encountered this year. The code originally looked like this:<br>
<br>
#define APP_TIMEOUT RTEMS_NO_TIMEOUT<br>
<br>
rtems_event_set events;<br>
<br>
(void) rtems_event_receive(<br>
<br>
     RTEMS_ALL_EVENTS,<br>
     RTEMS_EVENT_ANY | RTEMS_WAIT,<br>
     APP_TIMEOUT,<br>
     &events<br>
   );<br>
<br>
if (event & X) != 0) {<br>
<br>
...<br>
<br>
}<br>
<br>
Ok, you should check the return value, but ...<br>
<br>
Something didn't go well and someone changed APP_TIMEOUT:<br>
<br>
#define APP_TIMEOUT 1000<br>
<br>
Now, sometimes the rtems_event_receive() timed out and the application <br>
worked with events produced by the stack frame and not <br>
rtems_event_receive(). In the case of rtems_message_queue_receive() it <br>
would be the message size.<br>
<br>
In order to let broken applications fail a bit more gracefully, it would <br>
help to set the events and the message size to zero if the directive <br>
returns with an error. The modes could be set to the defaults, the <br>
priority to some invalid value, etc.<br>
<br>
What do you think?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">My first thought is that I don't like covering up for applications that do the wrong thing.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>