comparison between signed and unsigned

Discussion in 'C Programming' started by evanevankan2@hushmail.com, Jul 13, 2008.

  1. Guest

    I have a question about the warning 'comparison between signed and
    unsigned' I get from my code. It comes from the conditional in the
    outer for loop.
    I understand the warning, but I'm not sure what is the best way to
    prevent it. I can just change i to a type size_t or maybe put a cast
    in the conditional, but I don't know which way that is 'best'?
    Any ideas? I provided the code below for some context.

    And while we're at it, could you please check if the code looks good?

    And last question, the signed integer in the comparison will promoted
    to unsigned, right?
    Could you give some examples on what could go wrong when comparing
    signed and unsigned integers?

    Thanks

    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>

    static void *fail_malloc(size_t size)
    {
    void *ptr = malloc(size);

    if (ptr == NULL) {
    fprintf(stderr, "Memory allocation error\n");
    exit(EXIT_FAILURE);
    }

    return ptr;
    }

    typedef int insertion_compare(const void *insertion_a, const void
    *insertion_b);

    void insertion_sort(void *data, size_t nmemb, size_t size,
    insertion_compare *cmp)
    {
    int i, j;
    char *ptr = data;
    char *tmp = fail_malloc(size);

    for (i = 1; i < nmemb; i++) {
    memcpy(tmp, ptr + size * i, size);

    for (j = i - 1; j >= 0 && cmp(ptr + size * j, tmp) > 0; j--)
    {
    memmove(ptr + size * (j + 1), ptr + size * j, size);
    }

    memcpy(ptr + size * (j + 1), tmp, size);
    }
    free(tmp);
    }
     
    , Jul 13, 2008
    #1
    1. Advertising

  2. Guest

    On Jul 13, 5:17 pm, wrote:
    > I have a question about the warning 'comparison between signed and
    > unsigned' I get from my code. It comes from the conditional in the
    > outer for loop.
    > I understand the warning, but I'm not sure what is the best way to
    > prevent it. I can just change i to a type size_t or maybe put a cast
    > in the conditional, but I don't know which way that is 'best'?
    > Any ideas? I provided the code below for some context.
    >
    > And while we're at it, could you please check if the code looks good?
    >
    > And last question, the signed integer in the comparison will promoted
    > to unsigned, right?

    Only if all the values of the unsigned integer cannot be correctly
    represented by the signed integer type.
    > Could you give some examples on what could go wrong when comparing
    > signed and unsigned integers?
    >

    <snip>
    > for (j = i - 1; j >= 0 && cmp(ptr + size * j, tmp) > 0; j--)

    <snip>
    cmp() is not defined anywhere. That's a constraint violation and your
    code won't compile. Post compilable code.
     
    , Jul 13, 2008
    #2
    1. Advertising

  3. Guest

    I'm sorry for my previous reply in which I said 'cmp' is not defined
    anywhere. It's defined in the functions definition as a pointer to a
    function.

    On Jul 13, 5:17 pm, wrote:
    > I have a question about the warning 'comparison between signed and
    > unsigned' I get from my code. It comes from the conditional in the
    > outer for loop.
    > I understand the warning, but I'm not sure what is the best way to
    > prevent it. I can just change i to a type size_t or maybe put a cast
    > in the conditional, but I don't know which way that is 'best'?
    > Any ideas? I provided the code below for some context.

    Do you want to change your code? It's just a warning, comparing signed
    with unsigned doesn't invoke undefined behavior in any way.
    > And while we're at it, could you please check if the code looks good?
    >
    > And last question, the signed integer in the comparison will promoted
    > to unsigned, right?

    As I said before, only if the unsigned integers value cannot be
    correctly represented by the signed integer type.
    > Could you give some examples on what could go wrong when comparing
    > signed and unsigned integers?

    Nothing. Though the results, while defined, might be not the ones you
    expect, for instance:
    10u > -1
    is not true. -1 gets promoted to unsigned int, and becomes UINT_MAX.
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <string.h>
    >
    > static void *fail_malloc(size_t size)
    > {
    > void *ptr = malloc(size);
    >
    > if (ptr == NULL) {
    > fprintf(stderr, "Memory allocation error\n");
    > exit(EXIT_FAILURE);

    What if previous allocations succeded? Memory leak.
    > }
    >
    > return ptr;
    >
    > }
    >
    > typedef int insertion_compare(const void *insertion_a, const void
    > *insertion_b);
    >
    > void insertion_sort(void *data, size_t nmemb, size_t size,
    > insertion_compare *cmp)
    > {
    > int i, j;

    If you change these to size_t, your second for loop won't work,
    specifically the part j >= 0, which is always true, since j would be
    size_t, an unsigned integer.
    <snip>
     
    , Jul 13, 2008
    #3
  4. Guest

    On Jul 13, 4:21 pm, wrote:
    > On Jul 13, 5:17 pm, wrote:> I have a question about the warning 'comparison between signed and
    > > unsigned' I get from my code. It comes from the conditional in the
    > > outer for loop.
    > > I understand the warning, but I'm not sure what is the best way to
    > > prevent it. I can just change i to a type size_t or maybe put a cast
    > > in the conditional, but I don't know which way that is 'best'?
    > > Any ideas? I provided the code below for some context.

    >
    > > And while we're at it, could you please check if the code looks good?

    >
    > > And last question, the signed integer in the comparison will promoted
    > > to unsigned, right?

    >
    > Only if all the values of the unsigned integer cannot be correctly
    > represented by the signed integer type.


    Ok, thanks.

    > > Could you give some examples on what could go wrong when comparing
    > > signed and unsigned integers?

    >
    > <snip>
    > >           for (j = i - 1; j >= 0 && cmp(ptr + size * j, tmp) > 0; j--)

    >
    > <snip>
    > cmp() is not defined anywhere. That's a constraint violation and your
    > code won't compile. Post compilable code.


    cmp is the fourth argument to insertion_sort(), it compiles for me.
     
    , Jul 13, 2008
    #4
  5. Guest

    On Jul 13, 4:29 pm, wrote:
    > I'm sorry for my previous reply in which I said 'cmp' is not defined
    > anywhere. It's defined in the functions definition as a pointer to a
    > function.


    And I am sorry I missed this post before I replied to the first one.

    > On Jul 13, 5:17 pm, wrote:> I have a question about the warning 'comparison between signed and
    > > unsigned' I get from my code. It comes from the conditional in the
    > > outer for loop.
    > > I understand the warning, but I'm not sure what is the best way to
    > > prevent it. I can just change i to a type size_t or maybe put a cast
    > > in the conditional, but I don't know which way that is 'best'?
    > > Any ideas? I provided the code below for some context.

    >
    > Do you want to change your code? It's just a warning, comparing signed
    > with unsigned doesn't invoke undefined behavior in any way.


    No, if the comparison is ok in this case I don't feel the need to
    change it.

    > > And while we're at it, could you please check if the code looks good?

    >
    > > And last question, the signed integer in the comparison will promoted
    > > to unsigned, right?

    >
    > As I said before, only if the unsigned integers value cannot be
    > correctly represented by the signed integer type.
    > > Could you give some examples on what could go wrong when comparing
    > > signed and unsigned integers?

    >
    > Nothing. Though the results, while defined, might be not the ones you
    > expect, for instance:
    > 10u > -1
    > is not true. -1 gets promoted to unsigned int, and becomes UINT_MAX.'


    I understand. I guess I'll just have to be careful when doing such
    comparisons then.

    >
    > > #include <stdio.h>
    > > #include <stdlib.h>
    > > #include <string.h>

    >
    > > static void *fail_malloc(size_t size)
    > > {
    > >      void *ptr = malloc(size);

    >
    > >      if (ptr == NULL) {
    > >           fprintf(stderr, "Memory allocation error\n");
    > >           exit(EXIT_FAILURE);

    >
    > What if previous allocations succeded? Memory leak.


    Yeah, I usually don't write code like that that just aborts. I often
    see code with functions named xmalloc() that just bails out when
    memory allocation fails, don't like that, but this was only for
    testing so I decided to do it like that this time.

    > >     }

    >
    > >      return ptr;

    >
    > > }

    >
    > > typedef int insertion_compare(const void *insertion_a, const void
    > > *insertion_b);

    >
    > > void insertion_sort(void *data, size_t nmemb, size_t size,
    > >                     insertion_compare *cmp)
    > > {
    > >      int i, j;

    >
    > If you change these to size_t, your second for loop won't work,
    > specifically the part j >= 0, which is always true, since j would be
    > size_t, an unsigned integer.
    > <snip>


    I saw that changing 'j' would break the code, that's why I only said
    'i' in my first post. Having i and j as different types is pretty ugly
    IMHO, so I guess I'll just leave the code as it is.

    Thanks for the help!
     
    , Jul 13, 2008
    #5
    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. John Buckley

    comparison between signed and unsigned

    John Buckley, Oct 23, 2003, in forum: C Programming
    Replies:
    2
    Views:
    479
    Dan Pop
    Oct 24, 2003
  2. Alex
    Replies:
    3
    Views:
    646
    Michael Mair
    Apr 26, 2006
  3. Gary Wessle
    Replies:
    4
    Views:
    636
    Ian Collins
    Jul 29, 2006
  4. Replies:
    6
    Views:
    387
    Army1987
    Sep 21, 2007
  5. Lox
    Replies:
    13
    Views:
    2,280
    Joe Pfeiffer
    May 31, 2012
Loading...

Share This Page