Why is this statement being skipped?

I think that what's happening is that according to the obscure (to me, anyway) integral promotion rules, in the expression "a * b", the short int quantities a and b are both converted to int before the multiplication, so there is no overflow in this case. I think that if a and b were of type int, and the product of a and b was too big for an int but not for a size_t (for example on a 64-bit machine where int is 32 bits and size_t is 64 bits), then it would overflow with sizeof at the end, but not at the beginning (I'm not 100% sure since I'm still vague on the integral promotion rules). Can someone try it?

Could someone please run the following on a 64-bit machine where int is 32 bits and size_t is 64 bits, and post the output? Thanks. (The correct value of the expression is 0x400000000 if sizeof(int) == 4 and there is no overflow.)

Code:

---

#include <stdio.h>
#include <stddef.h>
int main(void) {
  printf("%lx\n", (unsigned long)(0x10000u * 0x10000u * sizeof(int)));
  printf("%lx\n", (unsigned long)(sizeof(int) * 0x10000u * 0x10000u));
  return 0;
}

---

Quote:

---

Originally Posted by robatino

Could someone please run the following on a 64-bit machine where int is 32 bits and size_t is 64 bits, and post the output? Thanks. (The correct value of the expression is 0x400000000 if sizeof(int) == 4 and there is no overflow.)

Code:

---

#include <stdio.h>
#include <stddef.h>
int main(void) {
  printf("%lx\n", (unsigned long)(0x10000u * 0x10000u * sizeof(int)));
  printf("%lx\n", (unsigned long)(sizeof(int) * 0x10000u * 0x10000u));
  return 0;
}

---

---

AMD 64bit machine, win xp (32bit), gcc compiler
result

Code:

---

0
0

---

> AMD 64bit machine, win xp (32bit), gcc compiler
size_t will still be at max 32-bits. He asked someone with a 64-bit machine, it's assumable to say a 64-bit compiler / OS.

Quote:

---

Originally Posted by zacs7

> AMD 64bit machine, win xp (32bit), gcc compiler
size_t will still be at max 32-bits. He asked someone with a 64-bit machine, it's assumable to say a 64-bit compiler / OS.

---

Yes, I should have specified it simply as "a platform where int is 32 bits and size_t is 64 bits". I'm guessing that in this case, the output will be

Code:

---

0
400000000

---

indicating that by putting the sizeof() at the beginning, the whole expression is computed using size_t (which needs to be bigger than unsigned int for it to matter) and overflow is avoided.

Why not use a 64-bit machine (OS/Compiler too) and use a unsigned long long in place of size_t (if it's not already implemented as so) and some signed 32-bit data type in place of int?

Someone's probably got an easy, snappy solution like "It's easy to see what's going on, you nubs" :)

Quote:

---

Originally Posted by zacs7

Why not use a 64-bit machine (OS/Compiler too) and use a unsigned long long in place of size_t (if it's not already implemented as so) and some signed 32-bit data type in place of int?

---

I'm trying to find out whether when passing an argument to malloc() (or any other kind of memory allocation function that takes a size_t) it's safer to put the sizeof(type) at the beginning instead of the end, which is conventional. I don't even want to think right now about the kind of error checking that would be needed to determine if the final value would overflow a size_t, before computing it (which would automatically mean that the allocation is impossible) - I just want to make sure that if the final result DOES fit in a size_t, it's computed correctly.

Quote:

---

Originally Posted by zacs7

> AMD 64bit machine, win xp (32bit), gcc compiler
size_t will still be at max 32-bits. He asked someone with a 64-bit machine, it's assumable to say a 64-bit compiler / OS.

---

ok.. didnt install xp64 as it suxx big time.. we had alot of driver probs