On Sat, Mar 27, 2021 at 01:44:07 +0100, Roland Illig wrote: > On 27.03.2021 00:16, Valery Ushakov wrote: > > On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote: > > > To me, writing 'sizeof expr' is clearer than 'sizeof(expr)' since > > > 'sizeof' is not a function, same as with 'return'. > > > > > > Did I misinterpret the style guide in this regard? > > > > We do want it to look like a function call (and so the usual style > > rules for the function call apply). Think of cases where it's used as > > a subexpression, e.g. > > > > sizeof(expr) + 4 > > The parentheses of a function call expression have highest precedence > and bind to the left. The parentheses to the right of the sizeof > operator do not bind at all though. Therefore I find it misleading to > write them like in a function call. > > The following code demonstrates why I prefer to omit the parentheses > around the argument to the 'sizeof' operator: [...] > /* misleading since it looks like a function call */ > printf("%zu\n", sizeof(argv)[3]); [...] > It was fun to find out that there actually _is_ a case where the > different precedence matters. At first I had thought that the whole > discussion would be academic anyway.
You cite examples worthy of IOCCC, but we already know C is treacherous (things like relative precedence of bitwise and comparison, etc). But most uses of sizeof are not like that. Note also that the parentheses are required fort the sizeof(type-name) variant. I.e. you cannot write sizeof int, only sizeof(int). IOCCC cases aside, I still maintain that sizeof *p + 4 is strictly less readable than sizeof(*p) + 4 and is nicely similar to sizeof(uint32_t) + 4 etc Derek Jones' "The New C Standard" (influential exegetical tour de force) doesn't seem to explicitly recommend parentheses for the unary-expr case but seems to consitently use it in its own text. -uwe