On Sat, Mar 28, 2020 at 9:38 PM Joel Sherrill <j...@rtems.org> wrote:
> We don't think you should assert or generate a fatal error after > initialization. This could cause an unknown, but safety critical, > application to fail. > > This same logic should be converted to a run-time error. > Should I just return RTEMS_INVALID_NUMBER if it goes out of bounds? We have fatal error manager to deal with all fatal or irrecoverable errors, do we have anything like that for run-time errors? Is there any function that can generate a run-time error? > > This is probably guidance that is or should be in the coding style in the > software engineering guide. If it isn't, please let us know. It needs a > small tasks ticket. > > --joel > > > On Sat, Mar 28, 2020, 5:50 AM G S Niteesh Babu <niteesh...@gmail.com> > wrote: > >> Fixes "array subscript is outside array bounds" in gpio-support.c >> --- >> bsps/shared/dev/gpio/gpio-support.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/bsps/shared/dev/gpio/gpio-support.c >> b/bsps/shared/dev/gpio/gpio-support.c >> index 9c053dc151..04f1c8ca90 100644 >> --- a/bsps/shared/dev/gpio/gpio-support.c >> +++ b/bsps/shared/dev/gpio/gpio-support.c >> @@ -325,6 +325,7 @@ static rtems_status_code get_pin_bitmask( >> ACQUIRE_LOCK(gpio_bank_state[bank].lock); >> } >> else if ( bank != *bank_number ) { >> + assert ( *bank_number >= 0 && *bank_number < GPIO_BANK_COUNT ); >> RELEASE_LOCK(gpio_bank_state[*bank_number].lock); >> >> return RTEMS_UNSATISFIED; >> -- >> 2.17.1 >> >>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel