[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Changed type signature" debug output
From: |
Wolfgang Lux |
Subject: |
Re: "Changed type signature" debug output |
Date: |
Tue, 17 Jan 2012 22:05:58 +0100 |
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 'address@hidden:address@hidden@address@hidden@44' to
>>> 'address@hidden:address@hidden@address@hidden@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:
"address@hidden:address@hidden@address@hidden@44"] methodType]);
It should print address@hidden:address@hidden@address@hidden@48. So it looks
like NSMethodTypeSignature is enforcing stricter alignment constraints than the
compiler.
Wolfgang