Fri 30 Jul 2004 05:32:04 PM UTC, comment #4:
It seems that this patch will cause problems when communicating to GNUstep processes that haven't been updated. I'm uncertain whether this can be resolved.
The issue again: GCC encodes the signature in a "relatively" platform indepenent way.It seems that this patch will cause problems when communicating to GNUstep processes that haven't been updated. I'm uncertain whether this can be resolved.
The issue again: GCC encodes the signature in a "relatively" platform independent way. I say "relatively" as it does mark arguments that it assumes are passed in registers with '+'. Yet it also assumes that every signature has @0: (see gcc/gcc/objc/objc-act.c). Yet the mframe code knows better. On some systems (like Solaris this produces warnings like:
2004-07-30 15:33:54.000 nsnotification[22083] File GSFFCallInvocation.m: 856.
In GSInvocationCallback Changed type signature
'Vv28@0:4@8@12@16C20@24' to
'Vv0@+8:+12@+16@+20@+24C+25@+28' for 'postNotificationName:object:userInfo:deliverImmediately:for:'
On other platforms (hppa) the the mframe code produces signatures with '-' to signalize parameters on the stack. Those would get registered with the runtime yet libobjc does not recognize those characters and once these signatures get registered, will abort.
So this is why I meant to differentiate between the libobjc/GCC signatures used within the process and the mframe signatures used for the FFI/FFCall code. Yet this seem to break callframe.m's assertion in
callframe_do_call():
NSCParameterAssert (sel_types_match(encoded_types, type));
on some platforms when DO is used with unpatched versions. I personally can't reproduce this but maybe Richard can help out on this.
|