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]

/* 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]

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

 

[Andrey Tarasevich]

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.

 

[joshc]

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]

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]

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.

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.

 

[Andrey Tarasevich]

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.

 

[joshc]

A couple of important corrections follow.
with

Should be "... wrap around zero/USHORT_MAX+1 limit ..."


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.

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


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

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]

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.

 

[Peter Nilsson]

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

ITYM: SHRT_MIN

 

[pete]

ITYM: SHRT_MIN

That's what I think too.

 

[joshc]

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


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

Things seem to get less clear... The code I'm working on has typedefs
like I mentioned for 16-bit, 32-bit, etc integer types, signed and
unsigned. The problem is that since the actual type, i.e. short or int,
etc. is hidden under the typedef how can I safely calculate the
absolute value of a negative number for type int16 and int32?

I think I understand from reading other threads that calculating the
absolute value of an 'int' can be achieved by: -(unsigned int)x;

The problem is for short ints like Andrey mentioned integer promotions
occur so it will be promoted to an int or unsigned int and this seems
to complicate things, especially when I don't know if the type I am
dealing with is actually a short or just an int since I am dealing with
int16, int32, etc.

Thanks.

 

[joshc]

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

Hmm, yes, after reading over 5.2.4.2.1 it seems that you are correct
about no guarantee that an integer type exists capable of representing
SHRT_MIN.

If you read my post further down below then I think I might not have to
deal with this problem because I am dealing with derived types such as
int16, int32, etc. and they are defined such that uint16_MAX = 65535
and int16_min = -32768... However, I am still confused about how to
achieve what I asked initially- computing the absolute value of int16
and int32...

 

[joshc]

dangers

Hmm, yes, after reading over 5.2.4.2.1 it seems that you are correct
about no guarantee that an integer type exists capable of representing
SHRT_MIN.

If you read my post further down below then I think I might not have to
deal with this problem because I am dealing with derived types such as
int16, int32, etc. and they are defined such that uint16_MAX = 65535
and int16_min = -32768... However, I am still confused about how to
achieve what I asked initially- computing the absolute value of int16
and int32...

After looking at 6.2.6.2 in the Standard, it seems that maybe there is
an implication that USHRT_MAX >= abs(SHRT_MIN) because unsigned short
and short have to occupy the same amount of storage and signed shorts
require 1 sign bit. I am a newcomer to actually reading the standard so
my explanation above is very likely incorrect and I'm looking for
feedback.

 

[CBFalconer]

.... snip ...

Hmm, yes, after reading over 5.2.4.2.1 it seems that you are
correct about no guarantee that an integer type exists capable
of representing SHRT_MIN.

How can you say that? The follow excerpt from N869 shows that
INT_MIN has to be capable of handling SHRT_MIN at their respective
minimums, and no implementor in his right mind would make a short
have a greater range than an int.

-- minimum value for an object of type short int
SHRT_MIN -32767 // -(215-1)

-- maximum value for an object of type short int
SHRT_MAX +32767 // 215-1

-- maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216-1

-- minimum value for an object of type int
INT_MIN -32767 // -(215-1)

 

[joshc]

How can you say that? The follow excerpt from N869 shows that
INT_MIN has to be capable of handling SHRT_MIN at their respective
minimums, and no implementor in his right mind would make a short
have a greater range than an int.

-- minimum value for an object of type short int
SHRT_MIN -32767 // -(215-1)

-- maximum value for an object of type short int
SHRT_MAX +32767 // 215-1

-- maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216-1

-- minimum value for an object of type int
INT_MIN -32767 // -(215-1)

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Nice, I was hoping for input from yourself or Eric Sosman who seem to
be the authority around here . As you can tell I am rather new to
actually reading the standard and understanding it but I think I
corrected myself in a later post.

How can you say that? The follow excerpt from N869 shows that
INT_MIN has to be capable of handling SHRT_MIN at their respective
minimums, and no implementor in his right mind would make a short
have a greater range than an int.

Anyways, isn't this not even up to the implementor?

6.2.5.8:

"8 For any two integer types with the same signedness and different
integer conversion rank
(see 6.3.1.1), the range of values of the type with smaller integer
conversion rank is a
subrange of the values of the other type."

Doesn't this guarantee what you are saying about INT_MIN having to be
at least as big as SHRT_MIN? I think what Andrey was saying though was
that no integer has to be capable of handling abs(SHRT_MIN). In my
later post I gave my understanding of this situation but I need it
confirmed.

Thanks.

 

[Keith Thompson]

How can you say that? The follow excerpt from N869 shows that
INT_MIN has to be capable of handling SHRT_MIN at their respective
minimums, and no implementor in his right mind would make a short
have a greater range than an int.

pete's comment upthread (which joshc inadvertentliy misrepresented)
was:
] It is not guaranteed that there is an integer type
] which is capable of representing the magnitude SHORT_MIN.

Obviously short (and all longer signed types) can represent SHORT_MIN,
but there may not be a type that can represent the absolute magnitude
of SHORT_MIN. For example, if short is 64 bits, SHORT_MIN could be
-2**63; they may not be a type that can represent +2**63. (I've used
systems where this is the case.)