[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