On 4 May 2012, at 12:27, Quentin Mathé wrote:
> -latestRevisionNumber method return type is int64_t. For methods doesn't
> return structs, I was expecting nil messaging to give a NULL or zero result.
> Is int64_t too big to be a safe return type for nil messaging?
I believe that on 32-bit platforms it generally is. I have a fix for this, but
I can't commit it until GNA lets me connect (I think I accidentally deleted the
ssh key my VM was using), but for now you can try the attached diff. The issue
is that your return value is in %eax and %edx, both of which are callee-safe
registers. The standard calling sequence for message sends with a nil
receiver, however, will USUALLY zero %edx as a side effect. This means that
message sends with a nil receiver will usually end up with the nil return
method returning 0 in %eax and will combine this with an existing 0 from %edx
to give a 64-bit zero.
In fact, I couldn't make clang or gcc emit a sequence where this doesn't
happen. You are probably seeing some combination of optimisation / register
allocator effects that means that the compiler is using %edx for something
non-zero just before the call.
David
-- Send from my Jacquard Loom
Index: sendmsg2.c
===================================================================
--- sendmsg2.c (revision 35121)
+++ sendmsg2.c (working copy)
@@ -9,7 +9,7 @@
void objc_send_initialize(id object);
-static id nil_method(id self, SEL _cmd) { return nil; }
+static long long nil_method(id self, SEL _cmd) { return 0; }
static struct objc_slot nil_slot = { Nil, Nil, 0, 1, (IMP)nil_method };
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
