Comparing singed to unsinged warning

Discussion in 'C Programming' started by Nevil Lesdog, Aug 23, 2007.

  1. Nevil Lesdog

    Nevil Lesdog Guest

    What do you think is the best way to handle a compiler warning about
    comparing an unsinged value to a singed value? Cast to silence it?
    Disable that warning altogether? Or just live with it?

    On one hand, the warning *could* be useful. Most of the time I get it in
    cases where I know the comparison is safe, but it's not hard to imagine
    that this won't always be the case. This makes disabling it undesirable.
    Casting is a workable solution, but I worry that changes in the code
    later could introduce errors that go undetected due to the cast. And I
    think we all hate not having a "clean" compile (if only because having a
    bunch of warnings that you expected makes it more difficult to spot the
    ones you didn't expect).

    What is your opinion?
     
    Nevil Lesdog, Aug 23, 2007
    #1
    1. Advertising

  2. Nevil Lesdog

    Al Balmer Guest

    On Thu, 23 Aug 2007 01:09:39 +0200 (CEST), Nevil Lesdog <>
    wrote:

    >What do you think is the best way to handle a compiler warning about
    >comparing an unsinged value to a singed value? Cast to silence it?
    >Disable that warning altogether? Or just live with it?


    Look at the code and make darned sure you understand why the warning
    occurred, and why it was necessary to compare things of two different
    type. Then, if you still think it was the right thing to do, use a
    cast, which will at least indicate that you did it on purpose.
    >
    >On one hand, the warning *could* be useful. Most of the time I get it in
    >cases where I know the comparison is safe, but it's not hard to imagine
    >that this won't always be the case. This makes disabling it undesirable.
    >Casting is a workable solution, but I worry that changes in the code
    >later could introduce errors that go undetected due to the cast. And I
    >think we all hate not having a "clean" compile (if only because having a
    >bunch of warnings that you expected makes it more difficult to spot the
    >ones you didn't expect).
    >
    >What is your opinion?


    My opinion is that there's a very good chance that the code could be
    better written.

    --
    Al Balmer
    Sun City, AZ
     
    Al Balmer, Aug 23, 2007
    #2
    1. Advertising

  3. Nevil Lesdog

    CBFalconer Guest

    Nevil Lesdog wrote:
    >
    > What do you think is the best way to handle a compiler warning about
    > comparing an unsinged value to a singed value? Cast to silence it?
    > Disable that warning altogether? Or just live with it?


    None of those. Consider whether values should be 'singed' or not.

    >
    > On one hand, the warning *could* be useful. Most of the time I get it in
    > cases where I know the comparison is safe, but it's not hard to imagine
    > that this won't always be the case. This makes disabling it undesirable.
    > Casting is a workable solution, but I worry that changes in the code
    > later could introduce errors that go undetected due to the cast. And I
    > think we all hate not having a "clean" compile (if only because having a
    > bunch of warnings that you expected makes it more difficult to spot the
    > ones you didn't expect).


    If a negative value ever appears in either compareee, the
    comparison is NOT safe.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Aug 23, 2007
    #3
  4. Nevil Lesdog

    pete Guest

    Nevil Lesdog wrote:
    >
    > What do you think is the best way to handle a compiler warning about
    > comparing an unsinged value to a singed value?
    > Cast to silence it?


    No.

    > Disable that warning altogether?


    No!

    > Or just live with it?


    No!!

    > On one hand, the warning *could* be useful.


    It most likely *is* useful.

    Rewrite the code so that there is no singed/unsinged mismatch,
    otherwise you might get signed by the heat.

    > Most of the time I get it in
    > cases where I know the comparison is safe,
    > but it's not hard to imagine
    > that this won't always be the case.
    > This makes disabling it undesirable.
    > Casting is a workable solution, but I worry that changes in the code
    > later could introduce errors that go undetected due to the cast. And I
    > think we all hate not having a "clean" compile
    > (if only because having a bunch of warnings that
    > you expected makes it more difficult to spot the
    > ones you didn't expect).
    >
    > What is your opinion?


    Change the sign type of one of your operands.

    --
    pete
     
    pete, Aug 23, 2007
    #4
  5. Nevil Lesdog

    Ark Khasin Guest

    pete wrote:
    > Nevil Lesdog wrote:
    >> What do you think is the best way to handle a compiler warning about
    >> comparing an unsinged value to a singed value?
    >> Cast to silence it?

    >
    > No.
    >
    >> Disable that warning altogether?

    >
    > No!
    >
    >> Or just live with it?

    >
    > No!!
    >
    >> On one hand, the warning *could* be useful.

    >
    > It most likely *is* useful.
    >
    > Rewrite the code so that there is no singed/unsinged mismatch,
    > otherwise you might get signed by the heat.
    >
    >> Most of the time I get it in
    >> cases where I know the comparison is safe,
    >> but it's not hard to imagine
    >> that this won't always be the case.
    >> This makes disabling it undesirable.
    >> Casting is a workable solution, but I worry that changes in the code
    >> later could introduce errors that go undetected due to the cast. And I
    >> think we all hate not having a "clean" compile
    >> (if only because having a bunch of warnings that
    >> you expected makes it more difficult to spot the
    >> ones you didn't expect).
    >>
    >> What is your opinion?

    >
    > Change the sign type of one of your operands.
    >

    In Steven Colbert's words, Here is your today's word: Wrap it!

    There are legitimate reasons why a mixed-signedness operations may be
    necessary.
    Imagine e.g. a function whose job is to scale and offset the argument,
    limit the result from above and from below and output it to a DAC register.
    An appropriate model for a DAC and perhaps for the lower and upper
    limits is unsigned, whereas for scaling and offsetting a natural model
    is signed.
    At some point, a leap from one signedness to the other is necessary.

    If the function is very small, a typecast (and a good comment) will do.
    Otherwise, wrap it in a proof that you know what you are doing, like

    #define INT2UINT(x) (assert((x)>=0),(unsigned)(x))

    assuming you don't pass it an expression with side effects. Or make an
    inline function to that effect.

    -- Ark
     
    Ark Khasin, Aug 23, 2007
    #5
  6. On Aug 22, 4:09 pm, Nevil Lesdog <> wrote:
    > What do you think is the best way to handle a compiler warning about
    > comparing an unsinged value to a singed value? Cast to silence it?
    > Disable that warning altogether? Or just live with it?
    >
    > On one hand, the warning *could* be useful. Most of the time I get it in
    > cases where I know the comparison is safe, but it's not hard to imagine
    > that this won't always be the case. This makes disabling it undesirable.
    > Casting is a workable solution, but I worry that changes in the code
    > later could introduce errors that go undetected due to the cast. And I
    > think we all hate not having a "clean" compile (if only because having a
    > bunch of warnings that you expected makes it more difficult to spot the
    > ones you didn't expect).
    >
    > What is your opinion?


    You could compare them using a dedicated function like in this
    program:

    #include <stdio.h>
    #include <limits.h>

    int CmpSU (int s, unsigned int u)
    // compares signed int s and unsigned int u;
    // returns: -1 if s < u
    // 0 if s == u
    // 1 if s > u
    {
    if (s >= 0)
    {
    if ((unsigned int)s < u) return -1;
    else if ((unsigned int)s > u) return 1;
    return 0;
    }
    return -1;
    }

    struct
    {
    int s;
    unsigned u;
    } aTestValues[] =
    {
    {INT_MIN, 0},
    {INT_MIN, 1},
    {INT_MIN, INT_MAX},
    {INT_MIN, UINT_MAX},
    {-1, 0},
    {-1, 1},
    {-1, INT_MAX},
    {-1, UINT_MAX},
    {0, 0},
    {0, 1},
    {0, INT_MAX},
    {0, UINT_MAX},
    {1, 0},
    {1, 1},
    {1, INT_MAX},
    {1, UINT_MAX},
    {INT_MAX, 0},
    {INT_MAX, 1},
    {INT_MAX, INT_MAX},
    {INT_MAX, UINT_MAX},
    };

    int main (void)
    {
    int i;
    for (i = 0;
    i < sizeof(aTestValues)/sizeof(aTestValues[0]);
    i++)
    {
    int s = aTestValues.s;
    unsigned int u = aTestValues.u;
    printf ("%d %c %u\n",
    s,
    "<=>"[1+CmpSU(s,u)],
    u);
    }
    return 0;
    }


    Alex
     
    Alexei A. Frounze, Aug 23, 2007
    #6
  7. Nevil Lesdog

    pete Guest

    Ark Khasin wrote:
    >
    > pete wrote:
    > > Nevil Lesdog wrote:
    > >> What do you think is the best way to handle a compiler warning about
    > >> comparing an unsinged value to a singed value?
    > >> Cast to silence it?

    > >
    > > No.
    > >
    > >> Disable that warning altogether?

    > >
    > > No!
    > >
    > >> Or just live with it?

    > >
    > > No!!
    > >
    > >> On one hand, the warning *could* be useful.

    > >
    > > It most likely *is* useful.
    > >
    > > Rewrite the code so that there is no singed/unsinged mismatch,
    > > otherwise you might get signed by the heat.
    > >
    > >> Most of the time I get it in
    > >> cases where I know the comparison is safe,
    > >> but it's not hard to imagine
    > >> that this won't always be the case.
    > >> This makes disabling it undesirable.
    > >> Casting is a workable solution, but I worry that changes in the code
    > >> later could introduce errors that go undetected due to the cast. And I
    > >> think we all hate not having a "clean" compile
    > >> (if only because having a bunch of warnings that
    > >> you expected makes it more difficult to spot the
    > >> ones you didn't expect).
    > >>
    > >> What is your opinion?

    > >
    > > Change the sign type of one of your operands.
    > >

    > In Steven Colbert's words, Here is your today's word: Wrap it!
    >
    > There are legitimate reasons why a mixed-signedness operations may be
    > necessary.
    > Imagine e.g. a function whose job is to scale and offset the argument,
    > limit the result from above and from below
    > and output it to a DAC register.
    > An appropriate model for a DAC and perhaps for the lower and upper
    > limits is unsigned, whereas for scaling and offsetting a natural model
    > is signed.
    > At some point, a leap from one signedness to the other is necessary.
    >
    > If the function is very small,
    > a typecast (and a good comment) will do.
    > Otherwise, wrap it in a proof that you know what you are doing, like
    >
    > #define INT2UINT(x) (assert((x)>=0),(unsigned)(x))
    >
    > assuming you don't pass it an expression with side effects. Or make an
    > inline function to that effect.


    That's all over my head.
    In my limited experience, I have never had to write code
    that used a relational operator
    with signed and unsigned operand types at the same time.

    The one time that I encountered it in a project that I was working
    on, the contract called for a clean compile and I had to fix it.
    Aside from generating a warning, the implicit conversion
    also rendered the controling expression of an "if" statement
    as always flase. I don't remember any other details
    except that I changed one of the types, so that
    the error condition that the code was supposed to check for,
    actually got checked for.

    --
    pete
     
    pete, Aug 24, 2007
    #7
  8. Nevil Lesdog

    Ark Khasin Guest

    pete wrote:
    > Ark Khasin wrote:
    >> pete wrote:
    >>> Nevil Lesdog wrote:
    >>>> What do you think is the best way to handle a compiler warning about
    >>>> comparing an unsinged value to a singed value?
    >>>> Cast to silence it?
    >>> No.
    >>>
    >>>> Disable that warning altogether?
    >>> No!
    >>>
    >>>> Or just live with it?
    >>> No!!
    >>>
    >>>> On one hand, the warning *could* be useful.
    >>> It most likely *is* useful.
    >>>
    >>> Rewrite the code so that there is no singed/unsinged mismatch,
    >>> otherwise you might get signed by the heat.
    >>>
    >>>> Most of the time I get it in
    >>>> cases where I know the comparison is safe,
    >>>> but it's not hard to imagine
    >>>> that this won't always be the case.
    >>>> This makes disabling it undesirable.
    >>>> Casting is a workable solution, but I worry that changes in the code
    >>>> later could introduce errors that go undetected due to the cast. And I
    >>>> think we all hate not having a "clean" compile
    >>>> (if only because having a bunch of warnings that
    >>>> you expected makes it more difficult to spot the
    >>>> ones you didn't expect).
    >>>>
    >>>> What is your opinion?
    >>> Change the sign type of one of your operands.
    >>>

    >> In Steven Colbert's words, Here is your today's word: Wrap it!
    >>
    >> There are legitimate reasons why a mixed-signedness operations may be
    >> necessary.
    >> Imagine e.g. a function whose job is to scale and offset the argument,
    >> limit the result from above and from below
    >> and output it to a DAC register.
    >> An appropriate model for a DAC and perhaps for the lower and upper
    >> limits is unsigned, whereas for scaling and offsetting a natural model
    >> is signed.
    >> At some point, a leap from one signedness to the other is necessary.
    >>
    >> If the function is very small,
    >> a typecast (and a good comment) will do.
    >> Otherwise, wrap it in a proof that you know what you are doing, like
    >>
    >> #define INT2UINT(x) (assert((x)>=0),(unsigned)(x))
    >>
    >> assuming you don't pass it an expression with side effects. Or make an
    >> inline function to that effect.

    >
    > That's all over my head.
    > In my limited experience, I have never had to write code
    > that used a relational operator
    > with signed and unsigned operand types at the same time.
    >
    > The one time that I encountered it in a project that I was working
    > on, the contract called for a clean compile and I had to fix it.
    > Aside from generating a warning, the implicit conversion
    > also rendered the controling expression of an "if" statement
    > as always flase. I don't remember any other details
    > except that I changed one of the types, so that
    > the error condition that the code was supposed to check for,
    > actually got checked for.
    >

    I don't think there is any disagreement at all.
    If you can refactor the code to avoid type mismatch, good. (And indeed
    in most cases I've seen a type mismatch, it /is/ the result of sloppy
    coding.)
    There are cases though where signedness change is necessary.

    -- Ark
     
    Ark Khasin, Aug 24, 2007
    #8
    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. Joseph Suprenant

    Unsinged char to int

    Joseph Suprenant, Aug 18, 2003, in forum: C Programming
    Replies:
    2
    Views:
    433
    Jan Engelhardt
    Aug 18, 2003
  2. Kevin Goodsell
    Replies:
    30
    Views:
    841
    Dan Pop
    Oct 22, 2003
  3. Replies:
    14
    Views:
    936
    Mark McIntyre
    Jan 28, 2006
  4. Jase Schick

    Unsinged types

    Jase Schick, Jul 2, 2010, in forum: C Programming
    Replies:
    11
    Views:
    583
    John Bode
    Jul 23, 2012
  5. Jase Schick

    Unsinged types

    Jase Schick, Jul 19, 2012, in forum: C Programming
    Replies:
    35
    Views:
    1,015
    Tim Rentsch
    Sep 7, 2012
Loading...

Share This Page