New Coverity Scan Results for RTEMS Available

[Sebastian Huber]

On 27/09/2018 17:59, Gedare Bloom wrote:
> On Thu, Sep 27, 2018 at 3:00 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 26/09/2018 15:42, Joel Sherrill wrote:
>>>
>>>
>>> On Wed, Sep 26, 2018 at 7:04 AM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de
>>> <mailto:sebastian.huber at embedded-brains.de>> 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 think this is acceptable in case it spans multiple tools in a
> relatively general way. For sure, we must avoid tool-specific
> annotations.

I added a ticket for rtems_task_exit():

https://devel.rtems.org/ticket/3533

>
>>> 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.

I think we need test cases for static analysis tools (maybe in a 
separate directory in the test suite) to figure out if they are able to 
understand the annotations.

-- 
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.huber at embedded-brains.de
PGP     : Public key available on request.

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