> Date: Sun, 2 Aug 2020 17:35:06 +0200
> From: Kamil Rytarowski <ka...@netbsd.org>
>
> On 02.08.2020 16:44, Taylor R Campbell wrote:
> >> Date: Sun, 2 Aug 2020 16:04:15 +0200
> >> From: Kamil Rytarowski <ka...@netbsd.org>
> >>
> >> On 02.08.2020 15:57, Taylor R Campbell wrote:
> >>> But it sounds like the original motivation is that it triggered
> >>> -Wvla...which frankly strikes me as a compiler bug since there's
> >>> obviously no actual VLA created in sizeof; as far as I can tell
> >>> there's no semantic difference between sizeof(device_t[n]) and
> >>> sizeof(device_t) * n.
> >>
> >> This is not true:
> >
> > Which part of what I said are you claiming is not true, and what are
> > you illustrating with the example program below?
>
> Calling it a compiler bug.
>
> Clang behaves the same way.
>
> $ clang -Wvla test.c
> test.c:6:37: warning: variable length array used [-Wvla]
> printf("sizeof = %zu\n", sizeof(int[argc]));
> ^
> 1 warning generated.
>
> Creating VLA is not needed for using it as an intermediate. In practice
> in most/all cases it is optimized and actual VLA is not allocated.
This is not a matter of optimization in practice. It's absolutely not
an `intermediate' at all -- there is no VLA created, period, any more
than sizeof(malloc(1)) causes any actual call to malloc or sizeof(*p)
causes any dereference of a pointer.
This makes -Wvla less useful as a tool, because apparently it flags
code that unquestionably does not have any bad effects of VLAs. This
happens because -Wvla is dumb -- it just looks for the syntax, not for
the semantics of creating VLAs. That's why I call it a bug -- it
raises a false positive that makes it less useful.
