Re: [Jack-Devel] packed data structures in jack2
Le 19 juil. 2012 à 19:32, Basil Nutmeg a écrit :
> On Thu, Jul 19, 2012 at 11:57:42AM -0400, Paul Davis wrote:
>> On Thu, Jul 19, 2012 at 11:41 AM, Basil Nutmeg <
>> [hidden]> wrote:
>>
>>>
>>> /* ... this type has the same layout between 32-bit and 64-bit. */
>>> struct A_with_alignment {
>>> aligned_char x;
>>> aligned_int64_t i;
>>> };
>>>
>>
>> this translates to:
>>
>> struct A_with_alignment {
>> char x __attribute__((aligned(sizeof(char));
>> int64_t i __attribute__((aligned(sizeof(int64_t));
>> };
>>
>> which i think is not the same as what "packed" does at all. it could be
>> enough though, and arguably is better because it preserves aligned access.
>
> Right, the goal isn't to emulate "packed" exactly; the goal is to solve a
> specific problem without incurring the undesirable side effects :-).
>
>>
>> however, as stephane noted: far easier to just change the macros that do
>> this stuff so that they are no-ops.
>
> This is easy to do, and it works for my project today. However, I was
> thinking about what would be best for Jack in the long term.
>
> I think it would be preferable to have a solution which could support
> mixed 64/32 mode even on platforms which don't have misaligned accesses
> (64-bit ARM chips are coming...), which would avoid the performance
> issues, and which would avoid "breaking the rules" even on platforms
> where it works, because clever compiler writers can still theoretically
> find ways to take advantage of alignment assumptions there. And it would
> undo what is technically an ABI break in the recent addition of "packed"
> to <jack/types.h>.
>
> I think it's even worthwhile to make moderately more invasive source
> changes to achieve this. And, I'm willing to do some work to help make it
> happen. But if the maintainers disagree, I'll move on.
Use a git branch.
>
>>
>>> 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.
>>>
>>
>> i don't this is portable to non-gnu compilers. i could be wrong.
>
> Perhaps so, or perhaps other compilers have analogous features; I don't
> know offhand. I'd be willing to do some research here. It might not be a
> complete solution, but it might be a nice sanity check, regardless.
>
> -- Basil
It has to work on Windows with VC++ and Mingw kid of compiler at least.
Stéphane
1342719447.19401_0.ltw:2,a <7C86BC8B-CE4D-4D80-99A4-C305701D960C at grame dot fr>