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

PrevNext  Index
DateMon, 07 Jan 2013 14:26:20 +0100
From Stéphane Letz <[hidden] at grame dot fr>
ToJohn Emmas <[hidden] at tiscali dot co dot uk>
CcJACK Mailing List <[hidden] at lists dot jackaudio dot org>
In-Reply-ToJohn Emmas 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)
Le 7 janv. 2013 à 14:12, John Emmas a écrit :

> 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 (?)

The issue here is only desirable for clients using the *public* jack headers (like type.h, jack.h)

We don't need to ensure that a server (so libjackserver.xx) compiled  with a given compiler can safely interact with the client side library (libjack.xx) compiled with another one. This has never been the goal! We assume that a JACK distribution always pack server and client side libraries compiled in a coherent manner (same compiler).

> 
> 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

OK.

Stéphane 
PrevNext  Index

1357565188.16065_0.ltw:2,a <196BE65E-2F55-4679-A8B0-B7E85863047C at grame dot fr>