View unanswered posts | View active topics It is currently Thu Jul 24, 2014 5:14 pm






Reply to topic  [ 2 posts ] 
3.05: sprintf wrong hexadecimal output 
Author Message
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 614
Post Re: 3.05: sprintf wrong hexadecimal output
This is expected behavior and corresponds to the definition of standard ANSI C behavior. The arguments to "sprintf" are what's called "VARARGS" (i.e. a variable length list of arguments). The definition of VARARGS is that each parameter is converted to a 32-bit value. So the cast to "long" (i.e. 32-bits is expected).

The size of an "int" in ROBOTC is 16-bits. This is fairly common among small embedded processors whose native word size is either 8 or 16 bits. ANSI allows size of 'int' to be implementation defined. Most big systems witll use 32-bits or even 64-bits. This is why you don't see the same kind of results on C running on windows because 'i' would be a 32-bit int.

Currently all ROBOTC platforms use 16-bit for int size. It would make sense that the larger platforms (LEGO NXT, VEX Cortex) use 32-bits. Eventually the int size will become a platform specific option.

The easiest fix for your sprintf is to specify the number of hex characters you want printed. Instead of using format code "%X" use "%4X" or "%04X" to get four hex digits printed. "%X" says print without any leading zeros and the print length is only the number of hex digits required. The value decimal 10 would print as "A" with format code "%X" and as "000A" or " A" with format codes "%04X" or "%4X".


Thu Feb 02, 2012 1:32 pm
Profile
Guru
User avatar

Joined: Sun Nov 15, 2009 5:46 am
Posts: 1347
Post Re: 3.05: sprintf wrong hexadecimal output
Yes, using %4x wouldn't help because it just specifies the minimum number of spaces used to print the number. If the number uses more spaces, it will ignore the 4. However, if you want to print in hex, you should use unsigned variable instead. When using signed variable, it is not uncommon that the compiler will "up convert" the signed value to the machine's natural integer size or even bigger. To avoid sign extending, it should use unsigned variables. Having said that, RobotC doesn't support unsigned values other than byte. I have complaint about that before :( because it makes RobotC not orthogonal (unsigned is not applicable to all data sizes). I still don't understand why this design decision is made. The only response I had was "RobotC is not ANSI C, so don't expect it to be compliant".


Fri Feb 03, 2012 4:32 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.