Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize.
Relying on what is printed out of printing a pointer value (which is not what the author is doing) is also misleading. Concluding stuff like "the size of an int is 4" or "size of double is 8" is also misleading. Again, it's not the conclusions the author is realizing, but for someone doing exploratory programming, it may be the case since the point of exploratory programming is learning by seeing how the system responds to the things you're doing.
And maybe I am wrong, but even the author got mislead by it.
"I'm going to ignore why 2147483648 == -2147483648; the point is that even arithmetic can be tricky in C, and gdb understands C arithmetic."
That's actually the result of undefined behavior, and not so much a result or "how C integer arithmetic works".
I really liked the idea. I just think it may be misleading if the tool you're using is GDB.
It'd be interesting a tool which allowed that sort of exploratory programming, but taking into consideration undefined behavior, unspecified things and implementation defined behavior.
The maximum int may be less than 2^31-1. Maybe your C implementation decides that your int type will be a 16bits object with values ranging from -2^15 to 2^15-1. In that case, that integer literal would not be an int, and is likely to be a long, and maybe, in this same implementation, a long is a 61bit object ranging from -2^63 to 2^63-1. In that case, that assertion is just plain false. That's not the system exposed in the article though. But it could happen in some other system.
Comments
Very interesting! But I'd say this is too dangerous because of the misleading conclusions that it'd "make" you realize.
Relying on what is printed out of printing a pointer value (which is not what the author is doing) is also misleading. Concluding stuff like "the size of an int is 4" or "size of double is 8" is also misleading. Again, it's not the conclusions the author is realizing, but for someone doing exploratory programming, it may be the case since the point of exploratory programming is learning by seeing how the system responds to the things you're doing.
And maybe I am wrong, but even the author got mislead by it.
"I'm going to ignore why 2147483648 == -2147483648; the point is that even arithmetic can be tricky in C, and gdb understands C arithmetic."
That's actually the result of undefined behavior, and not so much a result or "how C integer arithmetic works".
I really liked the idea. I just think it may be misleading if the tool you're using is GDB.
It'd be interesting a tool which allowed that sort of exploratory programming, but taking into consideration undefined behavior, unspecified things and implementation defined behavior.
That's not undefined, it's simply the bitwise representation of a 32 bits integer.
C allows more than 1 representation for integers. I know at least 3 possible ones: two's complement, ones' complement and signed magnitude.
The "natural wrap up" is not the same in all of the representations.
When the integer is unsigned, C gives you more guarantees, but for signed types, you're out of luck, and get to undefined bahvior land.
Check this out: http://web.torek.net/torek/c/numbers.html
And as an after note...
The maximum int may be less than 2^31-1. Maybe your C implementation decides that your int type will be a 16bits object with values ranging from -2^15 to 2^15-1. In that case, that integer literal would not be an int, and is likely to be a long, and maybe, in this same implementation, a long is a 61bit object ranging from -2^63 to 2^63-1. In that case, that assertion is just plain false. That's not the system exposed in the article though. But it could happen in some other system.
This can be true even on a 32bit system.