[PATCH 2/2] gpio/gpio-support: Fix build warnings.

[Niteesh G. S.]

On Sat, Mar 28, 2020 at 9:38 PM Joel Sherrill <joel at 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.gs at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200329/063c7b36/attachment.html>