On 27/09/2018 17:59, Gedare Bloom wrote:
On Thu, Sep 27, 2018 at 3:00 AM, Sebastian Huber
<sebastian.hu...@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.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.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
