[fpc-pascal] Carbon: i386 and PPC API differences

Jonas Maebe jonas.maebe at elis.ugent.be
Tue Sep 30 14:04:37 CEST 2008


On 30 Sep 2008, at 10:45, EarMaster - Bent Olsen wrote:

>> -----Original Message-----
>> From: fpc-pascal-bounces at lists.freepascal.org [mailto:fpc-pascal-
>> bounces at lists.freepascal.org] On Behalf Of Jonas Maebe
>> Sent: 29. september 2008 16:26
>> To: FPC-Pascal users discussions
>> Subject: Re: [fpc-pascal] Carbon: i386 and PPC API differences
>>
>> "const inDescription: ComponentDescription" is wrong, because FPC  
>> does
>> not guarantee that this will be passed by reference (especially in
>> case of C imports, because in C "const" also means "pass by value").
>> Either use a pointer type, or use "var" instead. There is no constvar
>> or similar specifier.
>>

I made a mistake here: when using the "mwpascal" calling convention,  
"const" in combination with a record does in fact always mean "pass by  
reference", because that's the meaning it also had with MetroWerks  
Pascal.

>> Also add {$packrecords C} to your source to ensure that the records
>> are properly packed, and translate "unsigned long" using the "culong"
>> type from the ctypes unit rather than using uint32 ("unsigned long"  
>> is
>> not the same as uint32 on all platforms, e.g. it's different on 64  
>> bit
>> Mac OS X).
>
> Thanks for the input, Jonas, and I went through all the declarations  
> and
> found that AUNode from the AUGraph.h was wrongly specified as  
> "Integer", and
> should be SInt32 as used in the C sample.
>
> That did a huge difference, and the sample is now works.

That also explains why it worked on Intel and not on PowerPC: on  
Intel, interpreting a 32 bit integer as a 16 bit integer is no problem  
as long as the value is < 65536. On PowerPC, such a declaration  
mismatch will however result in reading the upper 16 bits of the 32  
bit value.


Jonas



More information about the fpc-pascal mailing list