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

PrevNext  Index
DateMon, 07 Jan 2013 13:12:42 +0000
From John Emmas <[hidden] at tiscali dot co dot uk>
ToJACK Mailing List <[hidden] at lists dot jackaudio dot org>
In-Reply-ToPaul Davis Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
Follow-UpStéphane Letz Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
Follow-UpPaul Davis Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
Follow-UpAdrian Knoth Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
On 7 Jan 2013, at 13:02, Paul Davis wrote:

> 
> On Mon, Jan 7, 2013 at 7:55 AM, Stéphane Letz <[hidden]> wrote:
> 
> 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.
> 

Yes, Paul is right.  The 32-bit / 64-bit issue is only loosely connected to the topic of struct packing.  It's really significant benefit is the ability to allow a server built with one compiler to connect with clients built using a different compiler.  I'm assuming that would be a desirable goal for NetJack (?)

But we might be arguing unnecessarily here.  The first thing I should do is to test the new JACK_ALIGN strategy and see if it works as well as 1-byte packing used to work.  If it does, then there's no problem.

John
PrevNext  Index

1357564374.14827_0.ltw:2,a <0D2994C0-C361-40D8-B309-6EB7CA9E9635 at tiscali dot co dot uk>