Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)

PrevNext  Index
DateMon, 07 Jan 2013 08:02:56 -0500
From Paul Davis <[hidden] at linuxaudiosystems dot com>
ToStéphane Letz <[hidden] at grame dot fr>
CcJACK Mailing List <[hidden] at lists dot jackaudio dot org>
In-Reply-ToStéphane Letz Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
Follow-UpJohn Emmas Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
On Mon, Jan 7, 2013 at 7:55 AM, Stéphane Letz <[hidden]> wrote:

>
> > there is nearly always more than 1 way to skin a cat or pack a C
> structure. if __attribute__((packed)) has *any* room for interpretation, or
> if there is more than 1 way to pack a given structure to follow processor
> rules, then it does not accomplish your stated goal of ensuring compatible
> structure layouts between compilers.
> >
> > and i want to remind all readers that this discussion is ONLY about
> that. this has nothing to do with 32/64 issues.
> > it is solely about  ways to compile JACK with a compiler that uses one
> packing convention and end up with something usable by a client built with
> a different compiler.
> > 
>
> But we were dealing with those 32/64 issues with those PACKED struct right?
>

my recollection is that we reviewed the API and we removed all the
variably-sized elements from API. my recollections are often wrong these
days.

but yes, the original goal was "32/64 bit libjack connected to a 64/32 bit
jackd".  this means that whatever packing directives we use only have to
satisfy the (lesser) goal that the structures end up with the same packing
regardless of the target word size (for a given compiler).

john wants a more stringent goal, which is that the structures end up with
the same packing regardless of the compiler that is used.
PrevNext  Index

1357563783.13863_0.ltw:2,a <CAFa_cKnunea9UWbozh=UN5972mcEfAwVS5BxeD5odT4GssxA+w at mail dot gmail dot com>