uint32_t test(){
return 0;
}
void main()
uint32_t x = &test;
}
Is there any reason why x would not equal the address of test()?
I am trying to copy a function to another segment of memory, but & is giving me invalid results.
Yes, that is my entire code at this point, I may jsut be having a major brain lapse. But when I debug this program, x = 0x1002e185, test() = 0x100318c0
Quote from: Hdx on May 03, 2009, 09:03 PM
uint32_t test(){
return 0;
}
void main()
uint32_t x = &test;
}
Is there any reason why x would not equal the address of test()?
I am trying to copy a function to another segment of memory, but & is giving me invalid results.
Yes, that is my entire code at this point, I may jsut be having a major brain lapse. But when I debug this program, x = 0x1002e185, test() = 0x100318c0
Yeah, i don't know, but that's just wrong. test is the address of test(), not &test.
Does your code even compile?
What is uint32_t equal to? Is it a typedef struct?
Quote from: Yegg on May 03, 2009, 09:15 PM
What is uint32_t equal to? Is it a typedef struct?
Presumably it's an unsigned __int32 type.
Quote from: brew on May 03, 2009, 09:16 PM
Quote from: Yegg on May 03, 2009, 09:15 PM
What is uint32_t equal to? Is it a typedef struct?
Presumably it's an unsigned __int32 type.
I didn't want to make any assumptions. If it's just an unsigned int, why doesn't he use that instead?
Quote from: Yegg on May 03, 2009, 09:21 PM
Quote from: brew on May 03, 2009, 09:16 PM
Quote from: Yegg on May 03, 2009, 09:15 PM
What is uint32_t equal to? Is it a typedef struct?
Presumably it's an unsigned __int32 type.
I didn't want to make any assumptions. If it's just an unsigned int, why doesn't he use that instead?
Perhaps he has it jigged up some way in the header files so it's guarenteed to be an unsigned 32 bit integer regardless of chip architecture, word size, compiler, etc.
Quote from: brew on May 03, 2009, 09:23 PM
Quote from: Yegg on May 03, 2009, 09:21 PM
Quote from: brew on May 03, 2009, 09:16 PM
Quote from: Yegg on May 03, 2009, 09:15 PM
What is uint32_t equal to? Is it a typedef struct?
Presumably it's an unsigned __int32 type.
I didn't want to make any assumptions. If it's just an unsigned int, why doesn't he use that instead?
Perhaps he has it jigged up some way in the header files so it's guarenteed to be an unsigned 32 bit integer regardless of chip architecture, word size, compiler, etc.
Indeed, anyways, no shit my code compiles. In theory it should work correctly.
Quote from: Hdx on May 03, 2009, 09:27 PM
Indeed, anyways, no shit my code compiles. In theory it should work correctly.
No, it shouldn't compile at all. You're trying to assign a uint32_t the value of a *(*uint32_t)(). What compiler are you using?
VCE9
brew is correct. Your code has a lot of problems.
First, you should be casting to the correct type:
typedef uint32_t (*PU32FN)();
void main()
{
PU32FN x = &test; // x = test; should work as well, but this is more correct.
cout << x();
}
By not using pointer types your code is not 64-bit compatible. You might say "Well I'm not running 64-bit." I'll say this, though - at one point it will be common, and you should get into the habits now to not truncate pointer types.
I don't know how your code compiles; I get this error:
error C2440: 'initializing' : cannot convert from 'uint32_t (__cdecl *)(void)' to 'uint32_t'
Quote from: MyndFyre on May 04, 2009, 04:11 PM
brew is correct. Your code has a lot of problems.
First, you should be casting to the correct type:
typedef uint32_t (*PU32FN)();
void main()
{
PU32FN x = &test; // x = test; should work as well, but this is more correct.
cout << x();
}
By not using pointer types your code is not 64-bit compatible. You might say "Well I'm not running 64-bit." I'll say this, though - at one point it will be common, and you should get into the habits now to not truncate pointer types.
I don't know how your code compiles; I get this error:
error C2440: 'initializing' : cannot convert from 'uint32_t (__cdecl *)(void)' to 'uint32_t'
Unless you specifically tell your compiler to error on type cast warnings, it will simply display a warning and truncate it for you.
My point being, The code is simplistic, nothing you guys have done yet has changed the functionality of the code at all.
I have had a few other people comment on it. So i'm going to go with them. There blaming it on the debugger. And have offered examples of working code.
And Please for the love of god don't go into 32 vs 64 architectures, yes 64 will eventually become prevalent, and at that time, I will actually give a crap. My code is designed to run on my system, its is merely coincidence that it runs on anyone elses. If I was actually writing code for others to use, for anything consequential I can assure you that I would be more careful, but for the love of god do you guys REALLY think that's final code? seriously?