On Thu, Aug 19, 2010 at 1:56 PM, Yavor Doganov <ya...@gnu.org> wrote:
> Do you find anything disturbing in this approach, in particular:
Yes, you don't take into account the alignment requirement of the structure.
> --- Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28611)
> +++ Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28613)
> @@ -203,5 +203,18 @@
> #define GSNativeChar char
> #endif
>
> +/*
> + * Types used to avoid exposing pthread header in NSLock.h
> + * NB. These types should *never* be used except to provide enough space
> + * in a class layout for the type of data actually used by the pthread
> + * implementation of the current platform.
> + */
> +typedef struct {
> + uint8_t dum...@gs_sizeof_cond_t@];
> +} gs_cond_t;
> +typedef struct {
> + uint8_t dum...@gs_sizeof_mutex_t@];
> +} gs_mutex_t;
> +
>
> @GS_SIZEOF_COND_T@ and @GS_SIZEOF_MUTEX_T@ should be both 48 on hppa.
> (Mehdi/Dann, can you double check that by grepping GSConfig.h?)
>
> Apparently this trick works on all platforms (including hppa on Lenny,
> where I've run complex programs in my desire to reproduce).
The pthread_mutex_t and pthread_cond_t on hppa are __attribute__
((aligned(16))), which means if you embedded them into another
structure they need to be padded out to that alignment. The dummy
structure you use here doesn't match the alignment and may break ABI.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
