At 8:52 PM -0700 17/5/03, Gale Paeper wrote:
Since it is just a couple of packed types in the Mac interfaces and the size differences may not turn out to be of any importance upon more detailed investigation, I think the best way to work the changing size problem on those Mac interface types is through tweaking the few affected type declarations in the interfaces if it turns out necessary to do so. (I think the problem is with record alignment rather than field alignment which can be fixed with explict pad field declarations where MAC68K alignment implictly pads to achieve record alignment requirements.)
Yep, that was my conclusion. Also, a bunch of the differences are actually bogus, for example, under MAC68K and GPC alignment, records like this:
type rec = record a: UInt32; b: UInt32; extradatalength: UInt32; extradata: UInt8; end;
where extradata is actually just a placeholder to indicate an arbitrary amount of extra data, MAC68K would align the size at a multiple of 2 bytes, (so 14 for the above) whereas GPC would size them as 13 bytes). However no one would ever actually use either of these sizes or ever declare such a record explicitly, so the difference does not matter.
P.S. Since I don't think it would be of interest to the wider GPC audience, I didn't get into the details of the differences. Once I complete a few more investigations, I'll following up with the folks working on the Mac interfaces (e.g., Peter and Adriaan) on the nature of the problem and what interface changes, if any, are needed for correct interfacing functionality.
Please do, if you find any tweaking that needs to be done. I've already gone through all the records that don't exactly match the sizes under 68K and GPC (with the addition of the maximum-field-alignment option, this dropped to quite a small number), and convinced myself that there were no actual problematic cases left. However if you find any, please do let us know since otherwise the only way they will be found is with very confused programmers getting very weird results! Quite an ugly one to track down! Peter.