comparison between signed and unsigned

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);
}

re: comparison between signed and unsigned

On Jul 13, 5:17 pm, evanevank...@hushmail.com wrote:Only if all the values of the unsigned integer cannot be correctly
represented by the signed integer type.<snip><snip>
cmp() is not defined anywhere. That's a constraint violation and your
code won't compile. Post compilable code.

re: comparison between signed and unsigned

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, evanevank...@hushmail.com wrote:Do you want to change your code? It's just a warning, comparing signed
with unsigned doesn't invoke undefined behavior in any way.As I said before, only if the unsigned integers value cannot be
correctly represented by the signed integer type.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.What if previous allocations succeded? Memory leak.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>

re: comparison between signed and unsigned

On Jul 13, 4:21*pm, vipps...@gmail.com wrote:Ok, thanks.
cmp is the fourth argument to insertion_sort(), it compiles for me.

re: comparison between signed and unsigned

On Jul 13, 4:29*pm, vipps...@gmail.com wrote:And I am sorry I missed this post before I replied to the first one.
No, if the comparison is ok in this case I don't feel the need to
change it.
I understand. I guess I'll just have to be careful when doing such
comparisons then.
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.
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!

re: comparison between signed and unsigned

evanevankan2@hushmail.com wrote:Since there's no best way to define "best," you'll need
to use your own taste and judgement to evaluate advice. My
preference, for what it's worth, would be to change `i' and
`j' from int to size_t on the grounds that they are "like"
the size_t variable `nmemb'. (Note that changing `j' requires
a slight change in the inner loop: `j >= 0' becomes trivially
true.)

A counter-argument, also for what it's worth: Since an
int can count up to 32767 if not higher and since no one in
his right mind would use an insertion sort on more than a few
dozen elements, `nmemb' and `i' and `j' will always have small
values. Since a large range isn't needed, it might be more
efficient to use the "natural" int instead of the possibly more
cumbersome size_t. In this case, you'd want to demote `nmemb'
from size_t to int.

A counter-counter-argument: If efficiency is a concern, the
insertion sort itself is the problem and not the nature of the
indices it uses ...

--
Eric Sosman
esosman@ieee-dot-org.invalid