Velocity Reviews > unary negation operator question

# unary negation operator question

Peter Nilsson
Guest
Posts: n/a

 04-01-2005
pete wrote:
> 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;

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

ITYM: SHRT_MIN

--
Peter

pete
Guest
Posts: n/a

 04-01-2005
Peter Nilsson wrote:
>
> pete wrote:
> > 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;

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

>
> ITYM: SHRT_MIN

That's what I think too.

--
pete

joshc
Guest
Posts: n/a

 04-01-2005

pete wrote:
> 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

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?

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
Guest
Posts: n/a

 04-01-2005

pete wrote:
> 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;

>
> 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
Guest
Posts: n/a

 04-01-2005

joshc wrote:
> pete wrote:
> > 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;

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

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
Guest
Posts: n/a

 04-01-2005
joshc wrote:
>

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

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

joshc
Guest
Posts: n/a

 04-01-2005

CBFalconer wrote:
> joshc wrote:
> >

> ... 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)
>
> --
> "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
Guest
Posts: n/a

 04-01-2005
CBFalconer <(E-Mail Removed)> writes:
> joshc wrote:
>>

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

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

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post jimmij C++ 3 12-09-2006 10:42 AM SpOiLeR C++ 10 10-19-2005 01:18 PM John J C++ 7 04-18-2004 11:14 AM Francis Hwang Ruby 0 12-16-2003 04:07 AM MSDousti C++ 1 11-01-2003 07:52 PM