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

[christos%astron.com@localhost (Christos Zoulas)]

In article <YF6KPfrQxwDxKL8F%pony.stderr.spb.ru@localhost>,
Valery Ushakov  <uwe%stderr.spb.ru@localhost> wrote:
>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.

I think we should document we prefer the parenthesized version in style
and call it a day.

Best,

christos