unary negation operator question

[joshc]

I searched through the newsgroup for this and found the answer but
wanted to make sure because of something that came up.

I want the absolute value of a 'short int' so to avoid the dangers of
overflow I am doing the follow:

short int x = -4; /* want abs(x) */
unsigned short int abs_val;

....

/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;

I take it that the above is how I should safely get the absolute value
of a negative number. I want to confirm this because my Lint package
says that there is a:
"Loss of sign(assignment )(int to unsigned short)."

Thanks!

[joshc]

joshc wrote:

/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;

I take it that the above is how I should safely get the absolute value of a negative number. I want to confirm this because my Lint package
says that there is a:
"Loss of sign(assignment )(int to unsigned short)."

I just wanted to add that if I cast that whole thing to an unsigned
short int then I don't get that message but I'm still curious why Lint
warns me without the cast.

[Andrey Tarasevich]

joshc wrote:

...
I want the absolute value of a 'short int' so to avoid the dangers of
overflow I am doing the follow:

short int x = -4; /* want abs(x) */
unsigned short int abs_val;

...

/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;

I take it that the above is how I should safely get the absolute value
of a negative number.

Let's see what happens in this expression.

Initially, the operand ('x') is implicitly promoted to type 'int' (the
value is preserved). Then the conversion to 'unsigned short' causes the
original value to wrap around zero/SHORT_MAX+1 limit in accordance with
the rules of modulo arithmetics, i.e. the original negative value turns
into the positive value 'SHORT_MAX+1+x' . This value is once again
implicitly promoted to type 'int' (the value is preserved). And now the
unary '-' is applied to the operand, resulting in a negative value
'-SHORT_MAX-1-x' of 'int' type. Now, this final value is squeezed into a
variable of type 'unsigned short'. This will cause another wraparound.
The final value is positive '-SHORT_MAX-1-x+SHORT_MAX+1'. It is indeed
equal to '-x'.

It appears to be working (I hope I didn't miss anything), but if I were
you I wouldn't jump through all those hoops and employ all that
wraparound trickery to get to the negation of the original value. I
would do it this way instead

/* already performed check to make sure x is negative */
abs_val = -x;

This just makes more sense than the original version.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

joshc wrote:

joshc wrote:

/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;

I take it that the above is how I should safely get the absolute

value

of a negative number. I want to confirm this because my Lint package
says that there is a:
"Loss of sign(assignment )(int to unsigned short)."

I just wanted to add that if I cast that whole thing to an unsigned
short int then I don't get that message but I'm still curious why Lint
warns me without the cast.

I don't exactly understand why the above cast helps you to get rid of
the warning. But if you really want to use the cast, it would probably
make more sense to do it like this

abs_val = (unsigned short int) -x;

Read my previous message for more details.

--
Best regards,
Andrey Tarasevich

[joshc]

Andrey Tarasevich wrote:

Let's see what happens in this expression.

Initially, the operand ('x') is implicitly promoted to type 'int' (the value is preserved). Then the conversion to 'unsigned short' causes the original value to wrap around zero/SHORT_MAX+1 limit in accordance with the rules of modulo arithmetics, i.e. the original negative value turns into the positive value 'SHORT_MAX+1+x' . This value is once again
implicitly promoted to type 'int' (the value is preserved). And now the

I don't see why after the negation the value would be "implicity
promoted to type 'int'." I cast x to an (unsigned short int) so why
would it be cast back to a signed int?

It appears to be working (I hope I didn't miss anything), but if I were you I wouldn't jump through all those hoops and employ all that
wraparound trickery to get to the negation of the original value. I
would do it this way instead

/* already performed check to make sure x is negative */
abs_val = -x;

This just makes more sense than the original version.

The problem with that way is that you can have overflow if x =
SHRT_MIN because abs(SHRT_MIN) can be greater than SHRT_MAX.

[joshc]

Andrey Tarasevich wrote:

joshc wrote:

joshc wrote:

/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;

I take it that the above is how I should safely get the absolute

value

of a negative number. I want to confirm this because my Lint package says that there is a:
"Loss of sign(assignment )(int to unsigned short)."

I just wanted to add that if I cast that whole thing to an unsigned
short int then I don't get that message but I'm still curious why Lint warns me without the cast.

I don't exactly understand why the above cast helps you to get rid of
the warning. But if you really want to use the cast, it would

probably

What I meant was if I do the following:

abs_val = (unsigned short int)(-(unsigned short int)x);

That seems to get rid of the warning.

thx.

[Andrey Tarasevich]

joshc wrote:

...
Let's see what happens in this expression.

Initially, the operand ('x') is implicitly promoted to type 'int'

(the

value is preserved). Then the conversion to 'unsigned short' causes

the

original value to wrap around zero/SHORT_MAX+1 limit in accordance

with

the rules of modulo arithmetics, i.e. the original negative value

turns

into the positive value 'SHORT_MAX+1+x' . This value is once again
implicitly promoted to type 'int' (the value is preserved). And now

the

I don't see why after the negation the value would be "implicity
promoted to type 'int'." I cast x to an (unsigned short int) so why
would it be cast back to a signed int?

Speaking informally, C never performs any arithmetical computations on
types smaller than 'int'. Whenever you get a value of smaller type, that
value is immediately implicitly promoted to 'int' (or 'unsigned int', if
'int' is too narrow). This process is called 'integral promotion'. In
many cases it is purely conceptual, i.e. it doesn't really take place in
the final code, but it is still important to take it into account in
general case, because it can affect the final result.

It appears to be working (I hope I didn't miss anything), but if I

were

you I wouldn't jump through all those hoops and employ all that
wraparound trickery to get to the negation of the original value. I
would do it this way instead

/* already performed check to make sure x is negative */
abs_val = -x;

This just makes more sense than the original version.

The problem with that way is that you can have overflow if x =
SHRT_MIN because abs(SHRT_MIN) can be greater than SHRT_MAX.

Not really that simple. The original value of 'x', as I said above, is
promoted to 'int' before '-' is applied. And '-' is computed within the
bounds of type 'int', not within the bounds of type 'short'. However,
the overflow you describe is still possible if, for example, INT_MIN ==
SHORT_MIN and INT_MAX == SHOT_MAX. But that's more of a question of what
do you want to have as the final result in this case, not the problem
with this particular approach.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Andrey Tarasevich wrote:

...
I want the absolute value of a 'short int' so to avoid the dangers of
overflow I am doing the follow:

short int x = -4; /* want abs(x) */
unsigned short int abs_val;

...

/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;

I take it that the above is how I should safely get the absolute value
of a negative number.
Let's see what happens in this expression.

A couple of important corrections follow.
Initially, the operand ('x') is implicitly promoted to type 'int' (the
value is preserved). Then the conversion to 'unsigned short' causes the
original value to wrap around zero/SHORT_MAX+1 limit in accordance with
Should be "... wrap around zero/USHORT_MAX+1 limit ..."
the rules of modulo arithmetics, i.e. the original negative value turns
into the positive value 'SHORT_MAX+1+x' . This value is once again
USHORT_MAX+1+x
implicitly promoted to type 'int' (the value is preserved).
It is possible that at this stage the value is promoted to type
'unsigned short'. The choice depends on whether 'int' is large enough to
represent all 'unsigned short' values. If it is (USHORT_MAX <= INT_MAX),
'int' is chosen. Otherwise (USHORT_MAX > INT_MAX), 'unsigned int' is chosen.
And now the
unary '-' is applied to the operand, resulting in a negative value
'-SHORT_MAX-1-x' of 'int' type.
'-USHORT_MAX-1-x' of type 'int' if the previous promotion was to 'int'.

Otherwise, if the previous promotion was to 'unsigned int', the result
of unary '-' application is a positive value 'UINT_MAX-USHORT_MAX-x' of
type 'unsigned int'.
Now, this final value is squeezed into a
variable of type 'unsigned short'. This will cause another wraparound.
The final value is positive '-SHORT_MAX-1-x+SHORT_MAX+1'. It is indeed
equal to '-x'.

'-USHORT_MAX-1-x+USHORT_MAX+1' in case of 'int' promotion and the final
result is '-x'.

In case of 'unsigned int' promotion, the value of
'UINT_MAX-USHORT_MAX-x' will be wrapped around 'USHORT_MAX + 1' boundary
and it appears that it does not give the desired result in general case,
unless I'm missing something.

--
Best regards,
Andrey Tarasevich

[joshc]

Andrey Tarasevich wrote:

Andrey Tarasevich wrote:

...
I want the absolute value of a 'short int' so to avoid the dangers of overflow I am doing the follow:

short int x = -4; /* want abs(x) */
unsigned short int abs_val;

...

/* already performed check to make sure x is negative */
abs_val = -(unsigned short int)x;

I take it that the above is how I should safely get the absolute value of a negative number.
Let's see what happens in this expression.

A couple of important corrections follow.

Initially, the operand ('x') is implicitly promoted to type 'int' (the value is preserved). Then the conversion to 'unsigned short' causes the original value to wrap around zero/SHORT_MAX+1 limit in accordance with
Should be "... wrap around zero/USHORT_MAX+1 limit ..."

the rules of modulo arithmetics, i.e. the original negative value

turns into the positive value 'SHORT_MAX+1+x' . This value is once again

USHORT_MAX+1+x

implicitly promoted to type 'int' (the value is preserved).

It is possible that at this stage the value is promoted to type
'unsigned short'. The choice depends on whether 'int' is large enough

to represent all 'unsigned short' values. If it is (USHORT_MAX <= INT_MAX), 'int' is chosen. Otherwise (USHORT_MAX > INT_MAX), 'unsigned int' is chosen.

And now the
unary '-' is applied to the operand, resulting in a negative value
'-SHORT_MAX-1-x' of 'int' type.
'-USHORT_MAX-1-x' of type 'int' if the previous promotion was to

'int'.
Otherwise, if the previous promotion was to 'unsigned int', the result of unary '-' application is a positive value 'UINT_MAX-USHORT_MAX-x' of type 'unsigned int'.

Now, this final value is squeezed into a
variable of type 'unsigned short'. This will cause another wraparound. The final value is positive '-SHORT_MAX-1-x+SHORT_MAX+1'. It is indeed equal to '-x'.
'-USHORT_MAX-1-x+USHORT_MAX+1' in case of 'int' promotion and the

final result is '-x'.

In case of 'unsigned int' promotion, the value of
'UINT_MAX-USHORT_MAX-x' will be wrapped around 'USHORT_MAX + 1' boundary and it appears that it does not give the desired result in general case, unless I'm missing something.

--
Best regards,
Andrey Tarasevich

Thanks for reminding me about integer promotions. That kind of
complicates things for the short int case. My reasoning was based on
what I had read about calculating the absolute value of an "int" but as
you correctly pointed out that doesn't apply to short int.

So basically I have a bunch of typedef'd types like uint16, uint32,
int16, int32, etc. How can I make safe absolute value functions for
these types since their base types can be changed(so I don't know if
integer promotions will be applicable or not)?

I have seen plenty of threads on absolute value functions for "int" but
in light of the issues you brought up I am not clear as to how to
proceed.

Thanks.

[pete]

joshc wrote:

Andrey Tarasevich wrote:

joshc wrote:

joshc wrote:

> /* already performed check to make sure x is negative */
> abs_val = -(unsigned short int)x;
>
> I take it that the above is how I should
> safely get the absolute value
> of a negative number. I want to
> confirm this because my Lint package
> says that there is a:
> "Loss of sign(assignment )(int to unsigned short)."

I just wanted to add that if I cast that
whole thing to an unsigned
short int then I don't get that message
but I'm still curious why Lint
warns me without the cast.
I don't exactly understand why the above
cast helps you to get rid of
the warning. But if you really want to use the cast,
it would probably

What I meant was if I do the following:

abs_val = (unsigned short int)(-(unsigned short int)x);

That seems to get rid of the warning.

I recomend that you don't use small arithmetic types:
float, unsigned short, short, signed char, unsigned char, and char
in any way other than as array element types or string characters,
unless you have a special reason.

Also for
I want the absolute value of a 'short int' so to avoid the dangers of
overflow I am doing the follow:

short int x = -4; /* want abs(x) */
unsigned short int abs_val;

It is not guaranteed that there is an integer type
which is capable of representing the magnitude SHORT_MIN.

--
pete