On Sun, Apr 23, 2017 at 10:16:38PM +0200, Timo Buhrmester wrote: > > The main difference between you and Theo is that Theo knows what he's > > talking about.
> If you want to contribute anything, point out how casting a non-negative > into to size_t for comparison against another size_t could lead to > "real errors later whenever the code evolves in any way". Nice straw-man > with the s/world/code/, too. Sure makes it easier to appear to have a point. You definitely don't get it, do you ? people routinely change code in sweeping ways, and rely on the compiler to catch a lot of small mistakes. Say, somebody renames variables, and boom, after a few changes, you are casting a pointer into a size_t. Guess what ? you added a cast, so compiler doesn't warn (yes, I just checked, neither gcc nor clang warn on THAT one) I've seen bogus code countless times because a cast hid an horrid mistake. When you review code for mistakes and bugs, every time you see a cast, you have to check the variables, verify something isn't amiss. Because the compiler won't warn you. I have seen this countless times over the years. Like old X code playing mixing pointers and integers, and suddenly no longer working on 64 bit machines. Or somewhat more fun code using that old T *p = (T*)malloc(sz); idiom... Until there's T* on one side, and something else on the other side. Bottom line, each time, I read a cast, I have to slow down, and check it manually. I know the programmer did tell the compiler to explicitly SHUT THE FUCK UP, so the seat belts are GONE, not even detached, but completely BURNT THRU WITH NAPALM. *Whenever* I can avoid a cast, I do.
