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

PrevNext  Index
DateMon, 07 Jan 2013 08:28:37 -0500
From Paul Davis <[hidden] at linuxaudiosystems dot com>
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)
On Mon, Jan 7, 2013 at 8:12 AM, John Emmas <[hidden]> wrote:

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

not relevant. netjack defines (hahahahah) a protocol that is independent of
processor alignment or compiler behaviour.
PrevNext  Index

1357565324.16411_0.ltw:2,a <CAFa_cKm+axSgbqBvF6NWaqsaHxD+PRjjsvNX8OsArJescXM0kA at mail dot gmail dot com>