Fred Kiefer wrote:
> On 15.01.2012 15:12, Wolfgang Lux wrote:
>> Fred Kiefer wrote:
>>
>>> When starting up Ink with debug output enabled (openapp Ink/Ink
>>> --GNU-Debug=dflt) I get the following message a lot:
>>>
>>> File GSFFIInvocation.m: 604. In GSFFIInvocationCallback Changed
>>> type signature 'Vv52@0:8@16@24@32C40@44' to
>>> 'Vv56@0:8@16@24@32C40@48' for
>>> 'postNotificationName:object:userInfo:deliverImmediately:for:'
>>>
>>> I checked the various definition of that method that is implemented
>>> in base/Tools/gdnc.m and they all seem to match. I now think that
>>> the problem must be related to the size of BOOL, but I don't quite
>>> see how that could differ. Any explanation for that out there?
>>
>> Maybe it's not the size of BOOL but rather the compiler imposing
>> stricter alignment constraints with pointers aligned to a full word
>> (i.e., 8 byte) boundary?
>
> This may well be, but why should the same compiler use different
> alignment rules when compiling base/Source and base/Tools? That is, I still
> don't understand why this is happening :-(
I think the problem is in NSMethodSignature, which seems to reconstruct the
Objective-C types.
Try this on your machine:
printf("%s\n", [[NSMethodSignature signatureWithObjCTypes:
"Vv52@0:8@16@24@32C40@44"] methodType]);
It should print Vv56@0:8@16@24@32C40@48. So it looks like NSMethodTypeSignature
is enforcing stricter alignment constraints than the compiler.
Wolfgang
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
