Re: CVS commit: src/usr.bin/xlint

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

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