Re: Extern "C" -- Function Parameters Corrupted on Mactel??
Re: Extern "C" -- Function Parameters Corrupted on Mactel??
- Subject: Re: Extern "C" -- Function Parameters Corrupted on Mactel??
- From: Eric Albert <email@hidden>
- Date: Thu, 18 May 2006 00:55:39 -0700
On May 18, 2006, at 12:43 AM, Ben Weiss wrote:
On May 18, 2006, at 12:29 AM, Eric Albert wrote:
On May 18, 2006, at 12:14 AM, Ben Weiss wrote:
I'm running into a bizarre situation trying to combine C and C++
code as follows:
File: stuff.h:
extern "C" long Test2(long x, float y);
File: stuff.cpp:
long Test2(long x, float y) { return x + (long)y; } // or whatever
File: main.c:
long Test1(long x, float y) { return Test2(x, y); }
Inside Test1, the values for x and y are correct (say, 16 and 4,
respectively)... but when Test2 is entered, the value of y is
corrupted! (usually 0 or 1.0e-45 or something.) This is not just
a debugger issue; in my actual project the corrupted value causes
downstream code to crash.
The same code works perfectly on PowerPC; it only has this
problem on Mactel, and only with floating-point parameters. Is
there a compiler bug here, or am I overlooking something obvious?
This is the expected behavior when there's no prototype for Test2
in scope where it's called in Test1. Does main.c actually
#include stuff.h? I suspect it doesn't, because if it did you'd
have to write stuff.h something more like this:
#ifdef __cplusplus
extern "C"
#endif
long Test2(long x, float y);
because 'extern "C"' isn't valid in C code.
One great way to catch things like this is to build with -Wall.
Yep, that was it; thanks. The real mystery is why it was compiling
at all, let alone working "correctly" on PPC... Fixed, in any case.
It compiled because in C you don't actually have to declare the
functions that you call. Undeclared functions are assumed to take
ints for each of their arguments and return ints. They tend to work
reasonably well on PowerPC due to the calling convention there, but
the calling convention on Intel works in a way which means that these
cases tend to break.
Things like this are why I build all the code I can with -Wall -
Werror. Sometimes you end up fixing more warnings than you'd like,
but it means that you never spend hours debugging a problem like this
one....
-Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden