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".

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".