On Mon, Apr 24, 2017 at 12:01:10AM +0200, Marc Espie wrote: > 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 are talking about the code in question changing, I am talking about the environment around it changing. While I agree with you on a rule-of-thumb basis where casts are concerned, I don't see it as much as a blanket rule as you seem to do. Reminds me of people who will religiously try to spread the word that goto has no uses and must be avoided at all costs. > Say, somebody renames variables, and boom, after a few changes, you are > casting a pointer into a size_t. That's an odd thing to happen by renaming only. If the premise is that code can be broken by messing with it, that's trivially true and nothing you need to convince me of. In case you have missed it, the whole "changing the world" thing started as: > Unneccesary casts were among the hardest parts of the jump from 32-bit > to 64-bit, since a cast means "I know better than the compiler". > Well, when the world changes, that cast is suddenly wrong. And all I pointed out that the cast I proposed is safe from such changes in architecture, or new C standards, etc. And I still stand by that claim. Besides, I pointed out a real potential issue with the code that is completely independent of whether or not there is a cast, yet that's being ignored. This is my last reply in this pointless thread.
