On Tue, Mar 23, 2021 at 1:21 PM Gedare Bloom <ged...@rtems.org> wrote: > > On Tue, Mar 23, 2021 at 12:37 PM Joel Sherrill <j...@rtems.org> wrote: > > > > > > > > On Tue, Mar 23, 2021 at 12:58 PM Sebastian Huber > > <sebastian.hu...@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.hu...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel