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