Ah ok. I was bit by something similar a few years ago. I had
forgotten to put the prototype in my class interface and believed the
compiler was using a prototype from an unrelated class which had
different arg and return types. But the twist was the missing
prototype caused the default i
These sounded just the ticket... but unfortunately they generate
literally thousands of unwarranted warnings, so again, if they do pick
up genuine transgressions it is way below the noise floor.
Almost every call to a Cocoa instance method (or one private to my
code for that matter) generat
No, this is not it. The method definitely did have a prototype - in
fact it had *two*, differing only in return type. Judging by the
assembler code, it used the one returning an int (actually an enum)
not a float. It's still unclear why this generated code that trashed
memory, but it did. I
I suspect since the method had no prototype the compiler just assumed
the default id return type, but due to a bug didn't generate a
warning. The problem is most likely the calling method was expecting
the return value to be an integer (id; pointer) but instead is a
float. Even with a cas
On Jun 5, 2008, at 10:26 PM, Graham Cox wrote:
I guess the question is, given an object type 'id', which method
signature will the compiler go with? Does the return type affect the
method signature? (In C++ it doesn't for example), so two methods:
- (CGPoint) position;
- (float) position
On Jun 6, 2008, at 1:58 AM, Graham Cox wrote:
I agree, the compiler ought to be able to use the return type to
disambiguate two otherwise identically named methods (or warn of the
mismatch) - but it clearly doesn't.
My experimentation reveals, with the Xcode 2.5 tools, that the return
ty
On 05 Jun 08, at 22:58, Graham Cox wrote:
callL_objc_msgSend$stub
lealLC17-"L012$pb"(%ebx), %ecx
movl%eax, %edx
andl$65535, %edx
shrl$16, %eax
cvtsi2ss%eax, %xmm0
cvtsi2ss%edx, %xmm1
mulss
I agree, the compiler ought to be able to use the return type to
disambiguate two otherwise identically named methods (or warn of the
mismatch) - but it clearly doesn't.
This is interesting - I looked at the assembly code of the two cases.
Here's the code for the line:
float lp = [lh posi
On Fri, Jun 6, 2008 at 6:26 AM, Graham Cox <[EMAIL PROTECTED]> wrote:
> I guess the question is, given an object type 'id', which method signature
> will the compiler go with? Does the return type affect the method signature?
> (In C++ it doesn't for example), so two methods:
>
> - (CGPoint) posit
I guess the question is, given an object type 'id', which method
signature will the compiler go with? Does the return type affect the
method signature? (In C++ it doesn't for example), so two methods:
- (CGPoint) position;
- (float) position;
might well have identical signatures. The compi
On Thu, Jun 5, 2008 at 5:12 PM, Brian Stern <[EMAIL PROTECTED]> wrote:
> While float and int are the same size they are returned from functions in
> different registers (on both ppc and intel). If the calling function expects
> a float returned type but an int is returned instead the calling funct
On Thu, Jun 5, 2008 at 4:43 PM, Graham Cox <[EMAIL PROTECTED]> wrote:
> If I turn this on, I get thousands of warnings, none of which appear to be
> telling me anything useful (i.e. the code is perfectly legitimate). With
> that amount of noise if it does pick up the odd case like this I'm never
>
On Jun 5, 2008, at 11:26 AM, Graham Cox wrote:
OK, I found the culprit. As suspected, it has nothing to do with
sheets.
I'm using a sorting function with NSMutableArray:
static int cmpColorStops (DKColorStop* lh, DKColorStop* rh, void
*context)
In my original code, the sort function was
Hmmm, I don't think so. The docs say:
Warn if a prototype causes a type conversion that is different from
what would happen to the same argument in the absence of a prototype.
This includes conversions of fixed point to floating and vice versa,
and conversions changing the width or signedn
On Jun 5, 2008, at 9:26 AM, Graham Cox wrote:
It would be useful if there was a compiler warning for an implicit
cast or mismatch of return type in cases like this, because
otherwise they are devilishly hard to spot. If there is such a
warning, please tell me, so I can spare myself future h
OK, I found the culprit. As suspected, it has nothing to do with sheets.
I'm using a sorting function with NSMutableArray:
static int cmpColorStops (DKColorStop* lh, DKColorStop* rh, void
*context)
{
#pragma unused(context)
float lp = [lh position];
float rp =
16 matches
Mail list logo
