On 05/10/2018 08:57, Daniel Hellstrom wrote:
From: Jacob Hansen <jacob.han...@gaisler.com>
This commits bypasses a static assert when using the Clang compiler.
This is done as the static assertion does not compile with Clang
("static_assert expression is not an integral constant expression").
I am not sure this static assertion makes sense at all. SEM_FAILED
is used as a return value on failures from running sem_open(). Is
the test supposed to check that SEM_FAILED is defiend as NULL in the
included libraries (newlib) ? It is defiend as "(sem_t *) 0" in newlib.
The draft version of the posix standard, required sem_open to return -1, so
maybe this is an attempt to ensure that SEM_FAILED is actually defined?
But the compilation would failed if SEM_FAILED is not defined anyway.
I guess the check would make sense if somehow the code depended on
SEM_FAILED to be equal to NULL. But in that case I would think the code
should be updated to remove this dependency.
Looking at the source for sem_open at cpukit/posix/src/semopen.c it
seems that it uses the SEM_FAILED define as a return value, and I do not
see any dependencies on SEM_FAILED==NULL anywhere.
The change that introduces this code is:
"posix: Implement self-contained POSIX semaphores":
c090db7405b72ce6d0b726c0a39fb1c1aebab7ea
This static assertion ensures that POSIX_SEMAPHORE_VALIDATE_OBJECT()
rejects semaphore pointers with a SEM_FAILED value. We could change this
macro to test also for SEM_FAILED, but it would result in code like this
if (sem == 0 (aka NULL) || sem == 0 (aka SEM_FAILED) || ...)
See also:
https://gcc.gnu.org/ml/gcc-help/2018-10/msg00021.html
Coverity Scan crashes at this line too. GCC issues only a -Wpedantic
warning. In C++ the static assert would be fine. I am not sure how to
fix this.
--
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
