Sign extending unsigned number?

Go To Last Post
76 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So in other words buggy code was chosen to please novice programmers(maybe saving us from some type casts) and experienced programmers are expected to see these un written(hidden) type cast sign conversions that rarely happen, such as the one I have stumbled across.

 

Is that why these 3rd party programs were created to search for them (MISRA was mentioned earlier)

 

I'm curious is there a compiler switch to change this mode?

It would be interesting to try the other mode, It will obviously change a lot more than my shifts, but will be interesting what errors I come across.

 

If it wasn't a constant would it remain unsigned then?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your example wasn’t a constant. The TI compiler warns of the possibility of issues due to sign extension with constants such that you need to attach a type to the constant - eg 0x80UL. MISRA mandates you must do it.

Ulltimately it comes down to inferring a type and type conversion. In a strongly typed language like Pascal, you must explicitly do a type conversion and constants have a type. Anything else is an error. C takes the middle ground and doesn’t force you, but you’d better be sure you know what you’re doing. And that is the case here. Unless you explicitly guide the compiler, it is going to default to a set of rules in order to do a conversion. In your case the rules weren’t what you wanted. Thus the need for an explicit cast. It’s also not a rare case. Just about every bit of code I write there is explicit casts to ensure the compiler does what I want. If you think this is all voodoo magic, then look at other languages - try javascript and the rules of true and false! I lean on the IDE to alert me to these issues.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I couldn't find the C code I mentioned in post #46, but I did find some Java code which does the same thing. Now in Java, integers are always signed, unsigned integers are not supported (... well as of Java 8 there is partial support but let's not go there).

 

in a way that makes things easier when implicit up-casting occurs, but we still must handle the 0xFFFFFFC0 (for your case of 0xC0) created during sign extension by AND 0xfFF.

 

/**
 * Reads an signed 32-bit integer using little-endian byte order.
 *
 * @return the next four bytes of the input stream, interpreted as an
 *         signed 32-bit integer in little-endian byte order
 * @throws IOException if an I/O error occurs
 */
@Override
public int readInt32() throws IOException {
	int b1 = readAndCheckByte() & 0xFF;
	int b2 = readAndCheckByte() & 0xFF;
	int b3 = readAndCheckByte() & 0xFF;
	int b4 = readAndCheckByte();

	return ( (b4 << 24) + (b3 << 16) + (b2 << 8) + b1);
}

So you can see that even in an ultra formal language such as Java you still have to think really clearly when messing about with integers at bit level.

 

I hope this will see this thread "put to bed". I believe you now understand what is going on "under the hood" and also realise there is almost zero chance this behaviour will change.

 

So to paraphrase the words of the Borg: "The knowledge in this thread should be assimilated and added to your own. You will adapt to become a better programmer. Resistance is futile."

 

Have a Happy New Year.

Nigel

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

savman wrote:
I'm curious is there a compiler switch to change this mode?
GCC has:

       -Wsign-promo (C++ and Objective-C++ only)
           Warn when overload resolution chooses a promotion from unsigned or enumerated

           type to a signed type, over a conversion to an unsigned type of the same size.  Previous

           versions of G++ tried to preserve unsignedness, but the standard mandates the current

           behavior.

... but you'll have to switch to C++, and it only applies to overloading, not general expressions.

 

savman wrote:
So in other words buggy code was chosen
You seem to use the words 'code' and 'buggy' like 'smurf' or 'aloha', without really understanding what is at work here.

 

Any code is yours.  Any bugs are yours.  The language specification and the standard which governs it belong to the world.  If your beef is that the standard doesn't always meet your expectations, then join a long line-up.  Like any other group effort meant to satisfy an even larger group, it will be built upon compromise.  Complaints that the group effort doesn't always meet your expectations for 'common sense' are, frankly, laughable.  Every shred of documentation is freely available to you, and easy to find.  If that's not enough, all of the pertinent documentation has been referenced and/or copy/pasted into this thread for you.  Avail yourself of it, or don't.

 

Give up C.  Clearly you need a stronger hand, and a more strongly typed language.  Try Ada.  It is available for all of the platforms you work with.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

savman wrote:
So in other words buggy code was chosen to please novice programmers(maybe saving us from some type casts) and experienced programmers are expected to see these un written(hidden) type cast sign conversions that rarely happen, such as the one I have stumbled across.

 

[I swore I was going to stay out of this, but too good to pass up...]

 

Yup, I agree with you completely.  Like being sent on a snipe hunt or a search for left-handed monkey wrench, this is a rite of passage handed down from the creators of the C language.  For example, from K&R First Edition: