This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Gsoc 2014 project proposal
- From: Andrea Francesco Iuorio <andreafrancesco dot iuorio at gmail dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 26 Feb 2014 23:26:03 +0100
- Subject: Re: Gsoc 2014 project proposal
- Authentication-results: sourceware.org; auth=none
- References: <CAMaJsKjobBfmxjBRB2WP6MMLiAAD=QTV3bhO=hogeZHxmmotPg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402261759390 dot 11728 at digraph dot polyomino dot org dot uk> <CAMaJsKg-4WTvX+XPYXMYXHZvRvUotyYeq7O69Xye4WBE7Zw6Wg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402262139270 dot 17207 at digraph dot polyomino dot org dot uk>
2014-02-26 22:48 GMT+01:00 Joseph S. Myers <joseph@codesourcery.com>:
> 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.
I think i understand now. The important thing is that i must create
the union/struct directly in the typedef and avoid renaming. If
possible i should try to mantain the pthread types structure so i can
cast between them. I don' t understand one thing in the first
solution: why do you separate the architecture-dependent data ? Just
to have the same machine-dependent code in only one place ?
Thank you for your feedback, i didn' t really know this problematic (
and i know that until i' ll try to work on it i can' t really
understand it ) but now i can reprogram my schedule thinking about it.
Have you any other advice ?
--
Andrea Francesco Iuorio
Student in Computer Science, Università degli Studi di Milano
andreafrancesco.iuorio@gmail.com - GPG Key