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

[Corinna Vinschen <vinschen at redhat dot com>]

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?  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?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat