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

PrevNext  Index
DateSat, 12 Jan 2013 21:15:07 +0100
From Adrian Knoth <[hidden] at drcomp dot erfurt dot thur dot de>
To[hidden] at lists dot jackaudio dot org, Paul Davis <[hidden] at linuxaudiosystems dot com>
In-Reply-ToNedko Arnaudov 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-UpNedko Arnaudov Re: [Jack-Devel] JACK 1.9.10 to test (for 64/32 bits compatibility)
On 01/09/2013 05:09 PM, Nedko Arnaudov wrote:
> 
>>> But the problem with ABI mismatches between jack1 and jack2 is not
>>> solved.
>> Which one exactly? jack_latency_range_t?
>>
>> For jack_position_t, jackd1 does use packed structs:
>>
>>    https://github.com/jackaudio/headers/blob/master/transport.h#L40
> 
> jack2 does. This is why i'm talking about jack1/jack2 mismatches.

> https://github.com/jackaudio/jack2/blob/master/common/jack/types.h#L262
> https://github.com/jackaudio/jack2/blob/master/common/jack/types.h#L553

Your first link is a semi-valid point, your second is not, because
jackd1 also uses a packed jack_position_t.

So this leaves us with the single alignment (not even padding)
divergence between jackd1 and jackd2, which apparently is not a problem
on neither amd64 nor i386, since both "permit" 4-byte alignment for
uint32_t.

Things might be different on ARM, I don't have access to an ARM machine
to verify it.

Anyways, is there anything wrong with adding the PACKED statement to
jackd1's jack_latency_range type definition? Paul?


Cheers
PrevNext  Index

1358021718.2914_0.ltw:2,a <50F1C44B.5060001 at drcomp dot erfurt dot thur dot de>