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

[Ralf Corsepius]

On 02/28/2011 02:01 PM, Corinna Vinschen wrote:
> On Feb 28 13:29, Sebastian Huber wrote:
>> 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<...>
>>
>>          * 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<...>
>>
>>          * 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.
>
> I honestly don't know.
>
> Michael, I CCed you to have a word on this.
>
> Your aforementioned patch from 2009-06-17 added new definitions of
> PTHREAD_MUTEX_* for RTEMS and XMK, which collided with the already
> existing definitions guarded by _UNIX98_THREAD_MUTEX_ATTRIBUTES.
>
> However, three months later, you added a
>
>    #define _UNIX98_THREAD_MUTEX_ATTRIBUTES
>
> for XMK to sys/config.h, which essentially overruled the PTHREAD_MUTEX_*
> definitions you provided in June.  WHich of them are the right ones for
> XMK?  If backward compatibility is an issue, Sebastian's patch should
> do the right thing.  Is there anything which would speak for keeping the
> other values from 2009-06-17?
>
> As for RTEMS, the definition of _UNIX98_THREAD_MUTEX_ATTRIBUTES is from
> 2009-07-06.  As with XMK I'm wondering that nobody so far complained about
> the warnings.  However, to be really sure that we're doing the right thing,
> I would like to get somebody else from the RTEMS developers to comment on
> this issue.

Give me a couple of days ... I haven't yet had a chance to have a deeper 
look into Sebastian's patch and to investigate.

Ralf