Clang crash with unevaluated variable length array type

[EricPostpischil]

Put

int foo(void); 
int bar(void) { 
    return sizeof *(1 ? 0 : (char (*)[foo()]) 0); 
}

In a file named x.c and execute “clang -c x.c”.
This results in a crash. Output copied from Compiler Explorer (https://godbolt.org/z/bW6xvse7v) is:

Could not execute the program
Compiler returned: 254
Compiler stderr
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-trunk-20221115/bin/clang-16 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name example.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=constructor -dwarf-version=4 -debugger-tuning=gdb -fcoverage-compilation-dir=/app -resource-dir /opt/compiler-explorer/clang-trunk-20221115/lib/clang/16 -internal-isystem /opt/compiler-explorer/clang-trunk-20221115/lib/clang/16/include -internal-isystem /usr/local/include -internal-isystem /opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/app -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/example-850648.o -x c <source>
1.	<eof> parser at end of file
2.	<source>:1:20: LLVM IR generation of declaration 'bar'
3.	<source>:1:20: Generating code for declaration 'bar'
 #0 0x0000564afefad024 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x0000564afefaa8a4 SignalHandler(int) Signals.cpp:0:0
 #2 0x00007fe307810420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #3 0x0000564aff7c69e2 (anonymous namespace)::ScalarExprEmitter::EmitScalarConversion(llvm::Value*, clang::QualType, clang::QualType, clang::SourceLocation, (anonymous namespace)::ScalarExprEmitter::ScalarConversionOpts) CGExprScalar.cpp:0:0
 #4 0x0000564aff7d8af9 (anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) CGExprScalar.cpp:0:0
 #5 0x0000564aff7d21ba (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
 #6 0x0000564aff7d3fb7 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x42a6fb7)
 #7 0x0000564aff3ffe04 clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3ed2e04)
 #8 0x0000564aff401d35 clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3ed4d35)
 #9 0x0000564aff407d9a clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3edad9a)
#10 0x0000564aff46668d clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3f3968d)
#11 0x0000564aff471c16 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3f44c16)
#12 0x0000564aff4c81ba clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3f9b1ba)
#13 0x0000564aff4c4965 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3f97965)
#14 0x0000564aff4c4e53 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x3f97e53)
#15 0x0000564aff4cc5fa clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.0) CodeGenModule.cpp:0:0
#16 0x0000564b0023b2b1 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ModuleBuilder.cpp:0:0
#17 0x0000564b0022ddcd clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x4d00dcd)
#18 0x0000564b0143a074 clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x5f0d074)
#19 0x0000564b00238e15 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x4d0be15)
#20 0x0000564affb39471 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x460c471)
#21 0x0000564affabe103 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x4591103)
#22 0x0000564affc1cdab clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x46efdab)
#23 0x0000564afc813afc cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x12e6afc)
#24 0x0000564afc80eebc ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) driver.cpp:0:0
#25 0x0000564afc80f4df clang_main(int, char**) (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x12e24df)
#26 0x00007fe3072be083 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24083)
#27 0x0000564afc80bb3e _start (/opt/compiler-explorer/clang-trunk-20221115/bin/clang-16+0x12deb3e)
clang-16: error: unable to execute command: Segmentation fault (core dumped)
clang-16: error: clang frontend command failed due to signal (use -v to see invocation)

This appears to involve an omission in the C standard. For “1 ? 0 : (char (*)[foo()]) 0)”, the standard says the type of the conditional expression is the type of the third operand (because the second operand is a null pointer constant), but it is not evaluated, so the type is a variable length array whose length is not evaluated.

I do not have access to Compiler Explorer’s files to provide the requested script to replay Clang, sorry, but this seems easily reproducible. (On my own system, I use Apple Clang and have reported it separately to Apple.)

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[shafik]

Assertion:

lang-16: /root/llvm-project/clang/lib/CodeGen/CodeGenFunction.cpp:2171: 
clang::CodeGen::CodeGenFunction::VlaSizePair clang::CodeGen::CodeGenFunction::getVLASize(const clang::VariableArrayType*): 
Assertion `vlaSize && "no size for VLA!"' failed.

This looks related to: #58077

Slightly longer back trace:

PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -clear-ast-before-backend -main-file-name example.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=constructor -dwarf-version=4 -debugger-tuning=gdb -fcoverage-compilation-dir=/app -resource-dir /opt/compiler-explorer/clang-assertions-trunk-20221115/lib/clang/16 -internal-isystem /opt/compiler-explorer/clang-assertions-trunk-20221115/lib/clang/16/include -internal-isystem /usr/local/include -internal-isystem /opt/compiler-explorer/gcc-9.2.0/lib/gcc/x86_64-linux-gnu/9.2.0/../../../../x86_64-linux-gnu/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/app -ferror-limit 19 -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/example-24c278.o -x c <source>
1.	<eof> parser at end of file
2.	<source>:2:5: LLVM IR generation of declaration 'bar'
3.	<source>:2:5: Generating code for declaration 'bar'
 #0 0x000056235492d614 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x000056235492adc4 SignalHandler(int) Signals.cpp:0:0
 #2 0x00007f1fd4ef3420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #3 0x00007f1fd49c000b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
 #4 0x00007f1fd499f859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
 #5 0x00007f1fd499f729 (/lib/x86_64-linux-gnu/libc.so.6+0x22729)
 #6 0x00007f1fd49b0fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
 #7 0x0000562354e19ff2 clang::CodeGen::CodeGenFunction::getVLASize(clang::VariableArrayType const*) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x4476ff2)
 #8 0x0000562355189c25 clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
 #9 0x0000562355189ebb (anonymous namespace)::ScalarExprEmitter::Visit(clang::Expr*) CGExprScalar.cpp:0:0
#10 0x000056235518c2c5 (anonymous namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) CGExprScalar.cpp:0:0
#11 0x0000562355188b9b clang::StmtVisitorBase<std::add_pointer, (anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) CGExprScalar.cpp:0:0
#12 0x0000562355190064 clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x47ed064)
#13 0x0000562354da9f04 clang::CodeGen::CodeGenFunction::EmitReturnStmt(clang::ReturnStmt const&) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x4406f04)
#14 0x0000562354dabb9b clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*, llvm::ArrayRef<clang::Attr const*>) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x4408b9b)
#15 0x0000562354db1f34 clang::CodeGen::CodeGenFunction::EmitCompoundStmtWithoutScope(clang::CompoundStmt const&, bool, clang::CodeGen::AggValueSlot) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x440ef34)
#16 0x0000562354e10efe clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::Stmt const*) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x446defe)
#17 0x0000562354e23494 clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl, llvm::Function*, clang::CodeGen::CGFunctionInfo const&) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x4480494)
#18 0x0000562354e82029 clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x44df029)
#19 0x0000562354e7d295 clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x44da295)
#20 0x0000562354e7d933 clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x44da933)
#21 0x0000562354e86692 clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) (.part.0) CodeGenModule.cpp:0:0
#22 0x0000562355c62dc9 (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) ModuleBuilder.cpp:0:0
#23 0x0000562355c54bb0 clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x52b1bb0)
#24 0x0000562356f291e4 clang::ParseAST(clang::Sema&, bool, bool) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x65861e4)
#25 0x0000562355c5fd98 clang::CodeGenAction::ExecuteAction() (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x52bcd98)
#26 0x00005623554f0bb9 clang::FrontendAction::Execute() (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x4b4dbb9)
#27 0x000056235547764e clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x4ad464e)
#28 0x00005623555d5f53 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x4c32f53)
#29 0x0000562351e1d5e4 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x147a5e4)
#30 0x0000562351e193e7 ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) driver.cpp:0:0
#31 0x0000562351e1ab10 clang_main(int, char**) (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x1477b10)
#32 0x00007f1fd49a1083 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24083)
#33 0x0000562351e14d1e _start (/opt/compiler-explorer/clang-assertions-trunk-20221115/bin/clang-16+0x1471d1e)

[shafik]

CC @AaronBallman

[AaronBallman]

@erichkeane and I looked into this a bit and here's what we've discovered.

1. The size expression does not exist in the VLASizeMap, hence the assert.
2. CodeGenFunction::EmitVariablyModifiedType() is what sticks elements into that map.
3. ScalarExprEmitter::VisitUnaryExprOrTypeTraitExpr() only calls EmitVariablyModifiedType() if the sizeof operand is a type argument rather than an expression operand. Because it's an expression operand in this case, we call EmitIgnoredExpr() instead.
4. ScalarExprEmitter::VisitAbstractConditionalOperator() tries to aggressively ignore the branch-not-taken when it can, so nothing tries to emit the code for the VM type.

We're not completely certain of the correct way to solve this, though. As an experiment, I changed ScalarExprEmitter::VisitUnaryExprOrTypeTraitExpr() to:

    if (const VariableArrayType *VAT =
          CGF.getContext().getAsVariableArrayType(TypeToSize)) {
      // Make sure to emit the VLA size, which adds the size expression to our
      // VLA size expression map.
      CGF.EmitVariablyModifiedType(TypeToSize);
      if (!E->isArgumentType()) {
        // C99 6.5.3.4p2: If the argument is an expression of type
        // VLA, it is evaluated.
        CGF.EmitIgnoredExpr(E->getArgumentExpr());
      }

      auto VlaSize = CGF.getVLASize(VAT);
      llvm::Value *size = VlaSize.NumElts;
      ...

and zero tests broke, but that doesn't strike me as the correct approach. We could change getVLASize() to note when the VLA size expression isn't in the map and it can call EmitVariablyModifiedType(). We could change VisitAbstractConditionalOperator() to call EmitVariablyModifiedType() for the not-taken branch as well. Suggestions on the correct approach are welcome.

CC @rjmccall and @efriedma-quic

[efriedma-quic]

The C standard has the following language describing composite types: "if one type is a variable length array whose size is specified by an expression that is not evaluated, the behavior is undefined". I think it's supposed to apply to this case? In which case, we wouldn't evaluate the size at all; we just return poison or trap.

I'm not sure what it would mean to "evaluate" the size in this context, anyway; consider the following:

int foo(void), foo2(void), foo3(void);
int bar(void) { 
    return sizeof *(1 ? 0 : (foo() ? (char (*)[foo2()]) 0 : (char (*)[foo3()]) 0)); 
}

Do we call foo2() or foo3()? Or both?

[efriedma-quic]

We should probably open an issue with the standards committee to make the requirements here more explicit.

[AaronBallman]

Do we call foo2() or foo3()? Or both?

(After correcting the type incompatibility with the example) "Yes" https://godbolt.org/z/P6oaxWrMv :-D

The C standard has the following language describing composite types: "if one type is a variable length array whose size is specified by an expression that is not evaluated, the behavior is undefined". I think it's supposed to apply to this case? In which case, we wouldn't evaluate the size at all; we just return poison or trap.

I was thinking about this last night instead of sleeping and I don't think it applies in this case because both operands are not variable length arrays, they're pointers to variable-length arrays. So the type is variably-modified but is not itself a VLA (C2x 6.7.6p3). Based on that, I don't think we should invoke either (per C2x 6.5.3.4p2 -- it says "variable length array type" explicitly, not "variably modified type". So I am now thinking:

int foo(void); 
int bar(void) { 
    return sizeof *(1 ? 0 : (char (*)[foo()]) 0); 
}

this has a VM type, not a VLA type, and so foo() should not be evaluated. I tested the C compilers that support VLAs and... results are mixed (two compilers crash, two compilers emit a call to foo): https://godbolt.org/z/dM9h7nW58

CC @uecker who may have some good insights before I reach out to the WG14 reflectors.

[uecker]

Am Freitag, dem 02.12.2022 um 05:57 -0800 schrieb Aaron Ballman:

Do we call foo2() or foo3()? Or both?

I think this is unclear. The standard has some texts that specifies that the size expressions are evaluated for types of function parameters (before the function body) and typedef declarations (each time it is reached). It also  has wording saying that inside sizeof / typeof it is unspecified whether it is evaluted when it is not affecting the result of the operator (and maybe it is also not quite clear what this means for typeof), and not evaluated for alignof. But I can not find wording for the case of type names used for casts... (After correcting the type incompatibility with the example) "Yes" https://godbolt.org/z/P6oaxWrMv :-D The C standard has the following language describing composite types: "if one type is a variable length array whose size is specified by an expression that is not evaluated, the behavior is undefined". I think it's supposed to apply to this case? The answer depends on the question above. In which case, we wouldn't evaluate the size at all; we just return poison or trap. I do not see a reason for this. Poison or trap does not seem to be useful here, so I think clang should either ignore the expression if the result is not needed later or evaluate it unconditionally, instead of introducing another problem. Or maybe wait for WG14 guidance...

I was thinking about this last night instead of sleeping and I don't think it applies in this case because both operands are not variable length arrays, they're pointers to variable-length arrays. So the type is variably-modified but is not itself a VLA (C2x 6.7.6p3).

While this rule does not apply directly to VM-types, the rules for composite type apply recursively:  "These rules apply recursively to the types from which the two types are derived." So for pointers to VLAs the standard specified a recursion into the type it is derived from, i.e. the VLA, and then the rule is applied. I need to write a comment on compatible / composite types anyway, I will add this question. Martin

…

Based on that, I don't think we should invoke either (per C2x 6.5.3.4p2 -- it says "variable length array type" explicitly, not "variably modified type". So I am now thinking: int foo(void); int bar(void) {     return sizeof *(1 ? 0 : (char (*)[foo()]) 0); } this has a VM type, not a VLA type, and so foo() should not be evaluated. I tested the C compilers that support VLAs and... results are mixed (two compilers crash, two compilers emit a call to foo): https://godbolt.org/z/dM9h7nW58 CC @uecker who may have some good insights before I reach out to the WG14 reflectors. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: < ***@***.***>

[AaronBallman]

Thank you for the details, Martin!

I do not see a reason for this. Poison or trap does
not seem to be useful here, so I think clang should
either ignore the expression if the result is not
needed later or evaluate it unconditionally,
instead of introducing another problem.

Yeah, I'd want to know more about why poison or trap is better than defining the behavior before going down this path.

While this rule does not apply directly to VM-types,
the rules for composite type apply recursively:
"These rules apply recursively to the types from
which the two types are derived."

So for pointers to VLAs the standard specified
a recursion into the type it is derived from, i.e.
the VLA, and then the rule is applied.

Ah, thanks for pointing that out! Oofda though, what do we mean by "not evaluated" in that case? alignof arguments are unevaluated operands, so that obviously counts. But is the false branch of ?: "not evaluated" in the same sense? If so, is the false branch of if (...) ... else ... similarly "not evaluated".

C2x 6.5.15p5:

The first operand is evaluated; there is a sequence point between its evaluation and the evaluation
of the second or third operand (whichever is evaluated). The second operand is evaluated only if
the first compares unequal to 0; the third operand is evaluated only if the first compares equal to 0;
the result is the value of the second or third operand (whichever is evaluated), converted to the type
described below.

It says "evaluated only if", so I think it does apply. But for if statements, it gets more confusing:

C2x 6.8.4.1p2:

In both forms, the first substatement is executed if the expression compares unequal to 0. In the
else form, the second substatement is executed if the expression compares equal to 0. If the first
substatement is reached via a label, the second substatement is not executed.

Which says "executed" and not "evaluated"... and we don't define how "execute" differs from "evaluate" as best I can tell.

I'd think we intentionally want ?: to be a UB case and if to be a conforming case... but yeah, it's a bit unclear. I certainly hope that use of a VLA in a not-taken if branch is not UB because it's "an expression that is not evaluated". But making ?: semantically different from an if statement seems like a sharp edge for folks using VLAs.

[efriedma-quic]

The "poison or trap" thing was just going off the standard saying it's undefined. It would be better to modify the standard wording to something more friendly.