On Tue, Sep 19, 2017 at 8:16 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> Hello, > > we have to make some trade-offs in the implementation with respect to the > error checking. The operations get a pointer to the synchronization object, > e.g. > > int sem_post(sem_t *sem); > > int pthread_mutex_lock(pthread_mutex_t *mutex); > > Do we want to check for NULL pointers? > Is newlib consistently using the non-NULL declaration on the argument? Newlib/Cygwin folks have been pretty insistent that they do not want to check for NULL on the shared methods. Personally I hate to delete NULL argument pointer checks. Would a long-term compromise be to move them to argument checking macros that are enabled with --enable-rtems-debug? > > Do we want to check for other obviously invalid pointer values, e.g. > SEM_FAILED? > IMO Yes > Do we want to check if the object has been initialized? Yes. We want to have predictable behavior. > > glibc uses no checks at all. > Performance over correctness? That doesn't seem like a good trade. > > FreeBSD checks that the object has been initialized. For this purpose it > embeds a magic value field in the object structure. The drawback is that if > we also do this, the objects are not zero-initialized and thus cannot > reside in the BSS section. > This is an impossible trade. Some systems have big Flash and small RAM. Others are the opposite. I would rather follow the FreeBSD model and know the object is initialized. > > Destruction of synchronization objects in use is undefined behaviour > according to POSIX. Do we want to flush waiting threads during destruction? > This is a complex operation. > We have over 20 years of defined behavior in this case. I think we flush and return the same error we always did. Otherwise, we get a deadlock. > > What you think? > > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4 > <https://maps.google.com/?q=Dornierstr.+4&entry=gmail&source=g>, 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
