unary negation operator question

Discussion in 'C Programming' started by joshc, Apr 1, 2005.

  1. joshc

    joshc Guest

    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, Apr 1, 2005
    #1
    1. Advertising

  2. joshc

    joshc Guest

    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.
    joshc, Apr 1, 2005
    #2
    1. Advertising

  3. 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, Apr 1, 2005
    #3
  4. 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
    Andrey Tarasevich, Apr 1, 2005
    #4
  5. joshc

    joshc Guest

    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, Apr 1, 2005
    #5
  6. joshc

    joshc Guest

    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.
    joshc, Apr 1, 2005
    #6
  7. 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, Apr 1, 2005
    #7
  8. 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
    Andrey Tarasevich, Apr 1, 2005
    #8
  9. joshc

    joshc Guest

    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.
    joshc, Apr 1, 2005
    #9
  10. joshc

    pete Guest

    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
    pete, Apr 1, 2005
    #10
  11. 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
    Peter Nilsson, Apr 1, 2005
    #11
  12. joshc

    pete Guest

    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
    pete, Apr 1, 2005
    #12
  13. joshc

    joshc Guest

    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?

    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, Apr 1, 2005
    #13
  14. joshc

    joshc Guest

    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, Apr 1, 2005
    #14
  15. joshc

    joshc Guest

    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.
    joshc, Apr 1, 2005
    #15
  16. joshc

    CBFalconer Guest

    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
    CBFalconer, Apr 1, 2005
    #16
  17. joshc

    joshc Guest

    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.
    joshc, Apr 1, 2005
    #17
  18. CBFalconer <> 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.


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

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Apr 1, 2005
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. MSDousti

    c++ unary increment operator

    MSDousti, Nov 1, 2003, in forum: C++
    Replies:
    1
    Views:
    439
    Mike Wahler
    Nov 1, 2003
  2. John J

    unary operator- question

    John J, Apr 18, 2004, in forum: C++
    Replies:
    7
    Views:
    428
    osmium
    Apr 18, 2004
  3. SpOiLeR
    Replies:
    10
    Views:
    795
    SpOiLeR
    Oct 19, 2005
  4. jimmij

    negation operator !

    jimmij, Dec 8, 2006, in forum: C++
    Replies:
    3
    Views:
    787
    John Carson
    Dec 9, 2006
  5. Francis Hwang
    Replies:
    0
    Views:
    80
    Francis Hwang
    Dec 16, 2003
Loading...

Share This Page