Policy for return by reference values in error cases

[Gedare Bloom]

On Tue, Mar 23, 2021 at 1:21 PM Gedare Bloom <gedare at rtems.org> wrote:
>
> On Tue, Mar 23, 2021 at 12:37 PM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Tue, Mar 23, 2021 at 12:58 PM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> >>
> >> On 23/03/2021 18:48, Joel Sherrill wrote:
> >>
> >> > My first thought is that I don't like covering up for applications
> >> > that do the wrong thing.
> +.5
>
> >> This topic just came up recently in a discussion about defensive
> >> programming. We also test for NULL pointers.
> +1
>
> >> >
> >> > 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.
> >>
> >> You mean code like this:
> >>
> >> void (int *x, int y)
> >>
> >> {
> >>
> >>    *x = 0;
> >>
> >>   if (y) {
> >>
> >>     *x = 1;
> >>
> >> } else {
> >>
> >>   *x = 2;
> >>
> >> }
> >>
> >> ?
> >
> >
> > Yep. That's a pretty clear case.
> >
> > Others should speak up but I just don't want the solution pattern
> > to introduce warnings or static analysis reports. It easily could.
> >
>
> Generally, the error-producing path should allow the static analysis
> to find that the value gets set. In fact, I'm a bit surprised the
> static analysis doesn't complain about the original problem, that some
> variable can be used uninitialized when for example
> rtems_event_receive() returns before updating its pointer argument.
> Probably, the points-to analysis is complicated to find this case, but
> it seems like a good case to reduce and bring to some expert in static
> analysis.
>
I guess we don't have this kind of bad example in our testsuite though. :)

> So I don't see a fundamental problem with a pattern that initializes
> these out parameters at the top of the function to a default value.
>
> >
> >>
> >> > I don't want to see every error case assign a value to an output
> >> > parameter though.
> >> Yes, I don't like this also.
> >
> >
> > I have my own wish list for error paths eventually if we ever get bored. :)
> >
> >
> > --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