Re: New Coverity Scan Results for RTEMS Available

2018-09-27 Thread Sebastian Huber 



On 26/09/2018 15:42, Joel Sherrill wrote:



On Wed, Sep 26, 2018 at 7:04 AM Sebastian Huber 
> wrote:


On 26/09/2018 14:02, Sebastian Huber wrote:
> void rtems_task_delete_self() RTEMS_NORETURN;

Alternative would be

void rtems_task_exit(void) RTEMS_NORETURN;


I don't want to change APIs to make any static analysis tool happy.


Yes, just adding APIs to make a static analysis tool happy is not that 
great, however, we have to consider also the compiler which has a 
similar problem with the rtems_task_delete(RTEMS_SELF) function. We 
already tell the compiler that some functions do not return and I think 
an rtems_task_exit() would make sense too. For example we have in Newlib:


void    pthread_exit (void *__value_ptr) __dead2;


I used
Grammatech CodeSonar on RTEMS a few years ago and if we made it
happy, we would be very unhappy.

The best solution would be to figure out the Coverity modeling and 
annotation.
Then we could teach it our memory allocators, internal locks, etc..  I 
have a model
uploaded in our configuration but I admit to not having any confidence 
in making

Scan do anything with it. I found this:

https://stackoverflow.com/questions/42197018/how-do-i-use-coverity-modelling-to-mark-a-method-as-non-returning

But that looks to modify the source. I don't want to do more than 
simple annotation.

I don't want hacks like that in the real source.

I have an attempt at a model here 
(https://git.rtems.org/rtems-testing/tree/coverity)

and have uploaded it.


Maybe Coverity understands the clang thread safety annotations and the 
GCC attributes


__attribute__((__malloc__))
__attribute__((__alloc_size__(n, x)))

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Coverity Scan Results for RTEMS Available

2018-09-27 Thread Gedare Bloom 
On Thu, Sep 27, 2018 at 3:00 AM, Sebastian Huber
 wrote:
>
>
> On 26/09/2018 15:42, Joel Sherrill wrote:
>>
>>
>>
>> On Wed, Sep 26, 2018 at 7:04 AM Sebastian Huber
>> > > wrote:
>>
>> On 26/09/2018 14:02, Sebastian Huber wrote:
>> > void rtems_task_delete_self() RTEMS_NORETURN;
>>
>> Alternative would be
>>
>> void rtems_task_exit(void) RTEMS_NORETURN;
>>
>>
>> I don't want to change APIs to make any static analysis tool happy.
>
>
> Yes, just adding APIs to make a static analysis tool happy is not that
> great, however, we have to consider also the compiler which has a similar
> problem with the rtems_task_delete(RTEMS_SELF) function. We already tell the
> compiler that some functions do not return and I think an rtems_task_exit()
> would make sense too. For example we have in Newlib:
>
> voidpthread_exit (void *__value_ptr) __dead2;
>

I think this is acceptable in case it spans multiple tools in a
relatively general way. For sure, we must avoid tool-specific
annotations.

>> I used
>> Grammatech CodeSonar on RTEMS a few years ago and if we made it
>> happy, we would be very unhappy.
>>
>> The best solution would be to figure out the Coverity modeling and
>> annotation.
>> Then we could teach it our memory allocators, internal locks, etc..  I
>> have a model
>> uploaded in our configuration but I admit to not having any confidence in
>> making
>> Scan do anything with it. I found this:
>>
>>
>> https://stackoverflow.com/questions/42197018/how-do-i-use-coverity-modelling-to-mark-a-method-as-non-returning
>>
>> But that looks to modify the source. I don't want to do more than simple
>> annotation.
>> I don't want hacks like that in the real source.
>>
>> I have an attempt at a model here
>> (https://git.rtems.org/rtems-testing/tree/coverity)
>> and have uploaded it.
>
>
> Maybe Coverity understands the clang thread safety annotations and the GCC
> attributes
>
> __attribute__((__malloc__))
> __attribute__((__alloc_size__(n, x)))
>

I have a project that will put some time in to improving static
analysis of RTEMS over the next year or so. I will try to put some
effort into these problematic areas.

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> 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