Ternary conditional operator applied to two null handles:
class foo {}
void main() {
foo@ bar = true ? null : null;
}
Outcome: Compile error: Can't implicitly convert from '<null handle>' to 'foo@&'.
Expected outcome: Compiles, bar is initialized to null.
The expression has little use outside of temporary code / debugging, but it's reasonable to expect it to compile.
Auto initialized to null:
void main() {
auto foo = null;
}
Outcome: Null pointer access in asCDataType::CanBeInstantiated, crash.
Expected outcome: Compile error or foo is of null handle type.
Again, there is typically no reason to do this, and it's not necessary that it compile, but ideally the engine would not crash when given incorrect code.
Return reference to void:
void& f() {
return f();
}
Outcome: Compiles.
Expected outcome: Compile error: Data type cannot be reference to void.
Not very dangerous, because the only thing such a function can return is the result of another function that return void&, but this shouldn't be allowed to compile nonetheless.
Take reference to void:
void f(void &in, void &in) {}
void g() {}
void main() {
f(g(), g());
}
Outcome: Assertion failure in asCCompiler::ConvertToVariable.
Expected outcome: Compile error: Data type cannot be reference to void.
A more malicious version of the previous issue.
Void value used as argument of function that takes no arguments.
void f() {}
void main() {
f(f());
}
Outcome: Compiles, calls f twice.
Expected outcome: Compile error: Function f does not take arguments.
This is a bit of a special case, because I notice it's akin to C function definitions where functions that take no parameters are declared to take void, but wherever this kind of syntax is encountered, it appears to me that it's almost certain it's in error. Perhaps minimally a warning would be in place in this case.
