checksrc: make sure sizeof() is used *with* parentheses #2563
Conversation
Well... this has the drawback of not differencing |
Personally I don't make any distinction between those two versions in my head and I'm not sure why we need to make that distinction in the code. I so much prefer the paren version, especially when used in expressions like But perhaps more importantly, I don't see how we use sizeof paren vs non-paren consistently in the code now. This cleanup is mostly a fix to make us consistently always use the paren version. |
This is a bad example that would fail at compile time. Anyway, this is just a matter of styles and as in any open-source project, there are as many as contributors ! If this is a new rule, https://curl.haxx.se/dev/code-style.html should be updated to mention it. |
... and unify the source code to adhere.
I'll wait a while for some more feedback. This isn't in any hurry. Rebased and pushed to fix the merge conflict. |
No it wouldn't fail. We actually have exactly this line in the code right now:
... which is one of the lines that made me want to clean this up. For some reason I find that much harder to read than:
And allowing without paren in some situations but not in others were just too hard to make checksrc work with =) |
This one is OK, because Proof:
sizeof is an operator, not a function. It is followed either by an expression that may, as any expression, be parenthesed, or a parenthesed type (like a cast). You cannot have a type without parentheses. Not putting unneeded parenthesis is the emphasing I like to see in code, because it helps you knowing if you have to look for a variable or a typedef. See https://bytes.com/topic/c/answers/543699-sizeof-without-parenthesis |
Yes, you told. And I showed you a case using such a non-paren case that I think is inferior without parentheses. Clearly different tastes. |
I also sometimes do it without parentheses however I have no objection. I can see how having a space after the sizeof may require more cognitive processing to understand an expression. |
... and unify the source code to adhere.