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

[Corinna Vinschen <vinschen at redhat dot com>]

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.


Corinna