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

[Roland Illig <roland.illig%gmx.de@localhost>]

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:

#include <stdio.h>

int
main(int argc __attribute__((__unused__)), char **argv)
{
	/* misleading since it looks like a function call */
	printf("%zu\n", sizeof(argv)[3]);

	/* parentheses make the precedence unambiguous */
	printf("%zu\n", sizeof((argv)[3]));

	/* a space removes the confusion about precedence */
	printf("%zu\n", sizeof (argv)[3]);

	/* without any parentheses, spacing equals precedence */
	printf("%zu\n", sizeof argv[3]);

	/*
	 * If the parentheses to the right of 'sizeof' had the same
	 * precedence as function call parentheses, this artificial
	 * code could be written without the outer pair of parentheses.
	 */
	printf("%c\n", (sizeof(argv))["0123456789"]);

#if 0
	/*
	 * If 'sizeof' were a function returning size_t, this code
	 * would compile.
	 */
	/* error: array subscript is not an integer */
	printf("%c\n", sizeof(argv)["0123456789"]);
#endif
}

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.

Roland