Sunday, July 10, 2005

Odd address fatal alert-SelectOneTime killed by an int

Did you ever get a fatal alert with a message about how you supplied an odd address? You may now wonder what I am talking about-but please look at this bit of code:

TimeType t;
SelectOneTime(&t.hours, &t.minutes, "Text")


Looks innocent, doesn't it? But it crashes-at least on my T3! The fatal alert message can be misleading and point you in the direction of the Systrap-but actally, the adress of one of the parameters is wrong!

When you look at the definiton of the TimeType, you will see that minutes and hours are both int8's. The function-however-requires pointers to INT16 values! NBow, what happens can be described as follows. The first parameter would work as it is aligned on a 16bit border. But the second adress cannot be divided modulo 16 with 0 remainder-and thus the ARM processor cannot handle the operation and crashes!
The fixed version looks like this:

TimeType t;
int hours=t.hours;
int minutes=t.minutes;
SelectOneTime(&hours, &minutes, "Text")
t.hours=hours;
t.minutes=minutes;


Now, the function works with regular int's that have the processor's register length(an int is said to always have the host processors length(16 or 32bit)). There is no crash andmore, and the values still are preserved!

So, the next time coding, really be careful with your pointer types. Having an INT16 function return its value into an INT8 is ok if you know that the value will never exceed 255, but pointers are different. So, if you code a program that needs an int pointer next time, better check out its length.....
Ever had INT problems?

6 Comments:

Anonymous Anonymous said...

Also depends on the endianess of the CPU architecture you are coding for.

It does pay to be careful though, implicit casts are never good.

4:46 PM  
Blogger Steven Fisher said...

Hmm. That's very odd behaviour indeed. Codewarrior generates an error message for that sequence, for C as well as C++:

EError : illegal implicit conversion from 'unsigned char *' to
'short *'
Starter.c line 184 SelectOneTime(&t.hours, &t.minutes, "Text");

(The C++ error makes a lot less sense, but means the same thing.)

That makes me wonder what else your C compiler is letting you code that should generate an error (or at least a warning).

2:11 AM  
Blogger Tam Hanna said...

Hi,
originally I rasn OnBoardC-which permitted some stuff which was senseless and forbid other stuff which was useful(like setting the UInt32 address of a feature to a char array).
PODS permitted some stuff, and forbade some other. All of this until I created my DetypePtr routine that strips off the type from any pointer...
Best regards
Tam Hanna

1:24 PM  
Blogger Steven Fisher said...

There *is* a standard for how this should be handled, but I'm not wise enough to know what it is. :)

7:50 AM  
Blogger Tam Hanna said...

Hi,
I am a person who has learned that a standard without practical use is worthless.
Some of my routines cannot be ported because they cannot exist on other OSSes, so why should I take extreme care with pointer types there. If it works in my mind and on the hardware, I am happy! An example to this is the conversion of UInt32 to char*.
Best regards
Tam Hanna

1:24 PM  
Blogger aiya said...

Office 2010
Microsoft Office 2010
Microsoft word
Office 2007
Microsoft Office
Microsoft Office 2007
Office 2007 key
Office 2007 download
Office 2007 Professional
Outlook 2010
Microsoft outlook
Microsoft outlook 2010
Windows 7

8:29 AM  

Post a Comment

<< Home