> 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.