This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Avoid redefinitions in libc/include/sys/types.h in case __rtems__ is defined


On 02/28/2011 12:40 PM, Corinna Vinschen wrote:
> On Feb 24 13:44, Sebastian Huber wrote:
>> Hello,
>>
>> currently we have in Newlib for RTEMS:
>>
>> sys/types.h:393:0: warning: "PTHREAD_MUTEX_NORMAL" redefined
>> sys/types.h:310:0: note: this is the location of the previous definition
>> sys/types.h:394:0: warning: "PTHREAD_MUTEX_RECURSIVE" redefined
>> sys/types.h:325:0: note: this is the location of the previous definition
>> sys/types.h:396:0: warning: "PTHREAD_MUTEX_DEFAULT" redefined
>> sys/types.h:332:0: note: this is the location of the previous definition
>>
>> In <sys/features.h> we have
>>
>> #ifdef __rtems__
>> ...
>>  #define _UNIX98_THREAD_MUTEX_ATTRIBUTES         1
>> ...
>> #endif
>>
>> We include <sys/features.h> in <sys/types.h> before the PTHREAD_MUTEX_*
>> defines.  The _UNIX98_THREAD_MUTEX_ATTRIBUTES is also used in the RTEMS sources
>> to enable the attribute specific code.
>>
>> Why do we have different numeric values for the PTHREAD_MUTEX_* defines?
> 
> I'm not sure whom you're asking.
> 
> To me, this change looks a bit suspicious.  If _UNIX98_THREAD_MUTEX_ATTRIBUTES
> was defined for RTEMS and XMK for a while, the second set of definition of
> the PTHREAD_MUTEX values have ruled for a long time, right?  

Yes, it is there since:

2008-09-25  Raphael Derossa Pereira  <raphaelpereira@gmail.com>

        * libc/include/sys/types.h[_UNIX98_THREAD_MUTEX_ATTRIBUTES]: Add
        new mutex type values.
        (pthread_mutexattr_t)[_UNIX98_THREAD_MUTEX_ATTRIBUTES]: Add type
        field.

http://sourceware.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/sys/types.h.diff?r1=1.28&r2=1.29&cvsroot=src&f=h

> So what your
> patch is doing is to replace the so far used values with the overruled values
> from earlier in the file.  Doesn't that break backward compatibility?

You are right.  The earlier defines are from:

2009-06-17  Michael Eager <eager@eagercon.com>

        * libc/include/pthread.h: Support XMK (Xilinx) BSP, add RTEMS to
        PTHREAD_MUTEX_NORMAL.
        * libc/include/sys/types.h: Same.

http://sourceware.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/sys/types.h.diff?r1=1.29&r2=1.30&cvsroot=src&f=h

http://sourceware.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/sys/config.h.diff?r1=1.53&r2=1.54&cvsroot=src&f=h

RTEMS defines _UNIX98_THREAD_MUTEX_ATTRIBUTES in <sys/features.h> and XMK
defines it in <sys/config.h>.  Both header files will be included in <sys/types.h>.

So hopefully the attached patch is now correct.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschÃftliche Mitteilung im Sinne des EHUG.
Index: ./libc/include/sys/types.h
===================================================================
RCS file: /cvs/src/src/newlib/libc/include/sys/types.h,v
retrieving revision 1.35
diff -u -r1.35 types.h
--- ./libc/include/sys/types.h	15 Jan 2011 09:26:16 -0000	1.35
+++ ./libc/include/sys/types.h	28 Feb 2011 12:27:36 -0000
@@ -301,39 +301,6 @@
 #define PTHREAD_CREATE_DETACHED 0
 #define PTHREAD_CREATE_JOINABLE  1
 
-#if defined(__XMK__) || defined(__rtems__)
-/* The following defines are part of the X/Open System Interface (XSI). */
-
-/* This type of mutex does not detect deadlock. A thread attempting to relock this mutex without first unlocking 
- * it shall deadlock. Attempting to unlock a mutex locked by a different thread results in undefined behavior. 
- * Attempting to unlock an unlocked mutex results in undefined behavior. 
- */
-#define PTHREAD_MUTEX_NORMAL  1
-
-/* 
- * This type of mutex provides error checking. A thread attempting to relock this mutex without first unlocking 
- * it shall return with an error. A thread attempting to unlock a mutex which another thread has locked shall return 
- * with an error. A thread attempting to unlock an unlocked mutex shall return with an error. 
- */
-#define PTHREAD_MUTEX_ERRORCHECK  2 
-
-/* A thread attempting to relock this mutex without first unlocking it shall succeed in locking the mutex. 
- * The relocking deadlock which can occur with mutexes of type PTHREAD_MUTEX_NORMAL cannot occur with this type of mutex. 
- * Multiple locks of this mutex shall require the same number of unlocks to release the mutex before another thread can 
- * acquire the mutex. A thread attempting to unlock a mutex which another thread has locked shall return with an error. 
- * A thread attempting to unlock an unlocked mutex shall return with an error. 
- */
-#define PTHREAD_MUTEX_RECURSIVE  3
-
-/* Attempting to recursively lock a mutex of this type results in undefined behavior. Attempting to unlock a 
- * mutex of this type which was not locked by the calling thread results in undefined behavior. Attempting to 
- * unlock a mutex of this type which is not locked results in undefined behavior. An implementation may map this 
- * mutex to one of the other mutex types.
- */
-#define PTHREAD_MUTEX_DEFAULT  4 
-
-#endif /* defined(__XMK__) || defined(__rtems__) */
-
 #if defined(__XMK__)
 typedef struct pthread_attr_s {
   int contentionscope;

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]