Re: CVS commit: src/usr.bin/xlint
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
Re: CVS commit: src/usr.bin/xlint
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
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
Re: CVS commit: src/usr.bin/xlint
> > There are several forms of writing sizeof: > > 1. sizeof expr > 2. sizeof(expr) > 3. sizeof (expr) > 4. sizeof(type) > 5. sizeof (type) > > I thought that the point of the rule you cited was to discourage forms 3 > and 5. Does the rule also discourage form 1, and if so, why? > > 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? I think that this (no space after sizeof) is an unindented effect of the rule (preventing sizeof x). Having said that, most of the code uses sizeof(x) instead of sizeof x so I typically follow suit for consistency. Nevertheless we should mention what is the preferred style and document it clearly. christos signature.asc Description: Message signed with OpenPGP
Re: CVS commit: src/usr.bin/xlint
On Sat, Mar 27, 2021 at 00:01:25 +0100, Roland Illig wrote:
> > > Log Message:
> > > lint: in malloc calls, use 'sizeof *ptr' instead of 'sizeof(type)'
> >
> > style says "sizeof(" not "sizeof "
> >
> > * Casts and sizeof's are not followed by a space.
>
> There are several forms of writing sizeof:
>
> 1. sizeof expr
> 2. sizeof(expr)
> 3. sizeof (expr)
> 4. sizeof(type)
> 5. sizeof (type)
>
> I thought that the point of the rule you cited was to discourage forms 3
> and 5. Does the rule also discourage form 1, and if so, why?
>
> 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
-uwe
Re: CVS commit: src/usr.bin/xlint
On 26.03.2021 23:18, Christos Zoulas wrote:
In article <20210326203108.3a4e5f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Fri Mar 26 20:31:07 UTC 2021
Modified Files:
src/usr.bin/xlint/common: tyname.c
src/usr.bin/xlint/lint1: cgram.y decl.c err.c func.c init.c lex.c
main1.c mem1.c tree.c
src/usr.bin/xlint/lint2: chk.c emit2.c hash.c main2.c read.c
src/usr.bin/xlint/xlint: xlint.c
Log Message:
lint: in malloc calls, use 'sizeof *ptr' instead of 'sizeof(type)'
style says "sizeof(" not "sizeof "
* Casts and sizeof's are not followed by a space.
There are several forms of writing sizeof:
1. sizeof expr
2. sizeof(expr)
3. sizeof (expr)
4. sizeof(type)
5. sizeof (type)
I thought that the point of the rule you cited was to discourage forms 3
and 5. Does the rule also discourage form 1, and if so, why?
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?
Roland
Re: CVS commit: src/usr.bin/xlint
In article <20210326203108.3a4e5f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 26 20:31:07 UTC 2021
>
>Modified Files:
> src/usr.bin/xlint/common: tyname.c
> src/usr.bin/xlint/lint1: cgram.y decl.c err.c func.c init.c lex.c
> main1.c mem1.c tree.c
> src/usr.bin/xlint/lint2: chk.c emit2.c hash.c main2.c read.c
> src/usr.bin/xlint/xlint: xlint.c
>
>Log Message:
>lint: in malloc calls, use 'sizeof *ptr' instead of 'sizeof(type)'
style says "sizeof(" not "sizeof "
* Casts and sizeof's are not followed by a space.
christos
