Re: [Jack-Devel] packed data structures in jack2

They are some global PRE_PACKED_STRUCTURE and POST_PACKED_STRUCTURE

Why not just define them empty for your needs?

Stephane 

Le 19 juil. 2012 à 17:41, Basil Nutmeg a écrit :

> On Thu, Jul 19, 2012 at 06:54:41AM +0200, Stéphane Letz wrote:
>> The point to pack memory is to allow a 64 bits server to be used with 32 bits clients or the contrary. Since shared memory is going to be used by "both sides", the only safe way we found was to use packed memory struct.
> 
> Ah, thanks, I see now. I see how putting packed on everything does make
> this easier. However, it also makes the code unusable on some platforms
> and slow on others. Would you be open to alternative approaches here? I'd
> be willing to do some work to help out.
> 
> For example, here's one idea:
> 
> /*
> * To facilitate sharing data between 32-bit and 64-bit processes, we
> * use types that are fully aligned (aligned to their size), to avoid
> * differences in alignment rules. This macro facilitates creating
> * specially-aligned versions of basic types for this purpose.
> *
> * For example,
> *
> *     declare_aligned_type(int64_t);
> *
> * declares a typedef aligned_int64_t to be an int64_t that is always
> * aligned to an 8-byte boundary (assuming sizeof(int64_t) is 8...).
> */
> #define declare_aligned_type(T) \
>    typedef T aligned_##T __attribute__((aligned(sizeof(T))))
> 
> declare_aligned_type(char);
> declare_aligned_type(int64_t);
> /* ... and more */
> 
> /* And so, for example: */
> 
> /* While this type has a different layout between 32-bit and 64-bit... */
> struct A {
>  char x;
>  int64_t i;
> };
> 
> /* ... this type has the same layout between 32-bit and 64-bit. */
> struct A_with_alignment {
>  aligned_char x;
>  aligned_int64_t i;
> };
> 
> This would require more code changes than the packed approach, but it
> seems like it'd be pretty tolerable.
> 
> As another idea would be to have a source file which simply includes all
> the important headers and is compiled with -Wpadded and maybe even
> -Werror, to catch any mistakes.
> 
> You could even do both, for added safety.
> 
> What do you think? Or, if you don't like these approaches, is there
> anything else you might consider?
> 
> -- Basil

1342713274.9801_0.ltw:2,a <5DC5192E-D3C3-4BD7-96DB-F593EBE2D004 at grame dot fr>