(You may want to check your system's date, unless of course you traveled
in time.)
Russell Lewis wrote:
I'm of the opinion that we should make mixed-sign operations a
compile-time error. I know that it would be annoying in some
situations, but IMHO it gives you clearer, more reliable code.
The problem is, it's much more annoying than one might imagine. Even
array.length - 1 is up for scrutiny. Technically, even array.length + 1
is a problem because 1 is really a signed int. We could provide
exceptions for constants, but exceptions are generally not solving the
core issue.
IMHO, it's a mistake to have implicit casts that lose information.
Hear, hear.
Want to hear a funny/sad, but somewhat related story? I was chasing
down a segfault recently at work. I hunted and hunted, and finally
found out that the pointer returned from malloc() was bad. I figured
that I was overwriting the heap, right? So I added tracing and
debugging everywhere...no luck.
I finally, in desperation, included <stdlib.h> to the source file (there
was a warning about malloc() not being prototyped)...and the segfaults
vanished!!!
The problem was that the xlc compiler, when it doesn't have the
prototype for a function, assumes that it returns int...but int is 32
bits. Moreover, the compiler was happily implicitly casting that int to
a pointer...which was 64 bits.
The compiler was silently cropping the top 32 bits off my pointers.
And it all was a "feature" to make programming "easier."
Good story for reminding ourselves of the advantages of type safety!
Andrei
