Re: Gsoc 2014 project proposal

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Wed, 26 Feb 2014, Andrea Francesco Iuorio wrote:

> So, i can' t use a simple typedef because the type pthread_*_t is
> something in userland. This make sense as the functions name problem.
> I really didn' t think about it, it is the first time i try to create
> a system library. But i can' t also create a typedef __pthead_*_t
> because C++ don' t allow it ( and this it something that i didn' t
> honestly know ). So you suggest to create a struct or union that
> encapsulate the original type in the type i want. Am i right ? I need
> to know if i understand the problem correctly.

For example, at least some of the bits/pthreadtypes.h headers define 
pthread_mutex_t as

typedef union
{
  struct __pthread_mutex_s
  {
    (architecture-specific contents)
  } __data;
  char __size[__SIZEOF_PTHREAD_MUTEX_T];
  long int __align;
} pthread_mutex_t;

If that's what all architectures do, one option would be:

* bits/threadtypes.h defines struct __pthread_mutex_s and 
__SIZEOF_PTHREAD_MUTEX_T (and lots of other things, all in the reserved 
namespace).

* bits/pthreadtypes.h, possibly now architecture-independent, includes 
bits/threadtypes.h and does:

typedef union
{
  struct __pthread_mutex_s __data;
  char __size[__SIZEOF_PTHREAD_MUTEX_T];
  long int __align;
} pthread_mutex_t;

* threads.h includes bits/threadtypes.h and does:

typedef union
{
  struct __pthread_mutex_s __data;
  char __size[__SIZEOF_PTHREAD_MUTEX_T];
  long int __align;
} mtx_t;

Or the common header could do

#define __pthread_mutex_t_contents \
  union \
  { \
    ... \
  }

and then the other headers would do

typedef __pthread_mutex_t_contents pthread_mutex_t;

and

typedef __pthread_mutex_t_contents mtx_t;

which would avoid duplication of the list of three union fields.

There are various such options.  The basic requirement is that after macro 
expansion the pthread_mutex_t definition looks like

typedef union { ... } pthread_mutex_t;

where the union does not have a tag, so that the C++ name mangling is 
unchanged.  And, so that you can cast pointers appropriately, the two 
types need the same contents.

-- 
Joseph S. Myers
joseph@codesourcery.com