The post’s example of undefined behavior via signed integer overflow still holds in current V master. $ cat test.v fn main() { x := i32(2147483

The post’s example of undefined behavior via signed integer overflow still holds in current V master. $ cat test.v fn main() { x := i32(2147483647) + 1 println(x) } $ ./v version V 0.3.0 f0cee25 $ ./v -o test.c test.v $ cc -fsanitize=undefined -Lthirdparty/tcc/lib -Ithirdparty/libgc/include test.c -lgc test.c: In function 'main__main': test.c:12073:37: warning: integer overflow in expression of type 'int' results in '-2147483648' [-Woverflow] 12073 | int x = ((i32)(2147483647)) + 1; | ^ $ ./a.out test.c:7577:33: runtime error: signed integer overflow: -2147483648 - 2147483600 cannot be represented in type 'int' -2147483648 That V code has compiled to this C code, which is indeed undefined behavior. VV_LOCAL_SYMBOL void main__main(void) { int x = ((i32)(2147483647)) + 1; println(int_str(x)); } (Since you asked for people to file issues about these problems, I’ve opened https://github.com/vlang/v/issues/14912 https://github.com/vlang/v/issues/14912.) Additionally, V’s own documentation calls out a separate instance of undefined behavior (https://github.com/vlang/v/blob/master/doc/docs.md#closures https://github.com/vlang/v/blob/master/doc/docs.md#closures): “If you need the value to be modified outside the function, use a reference. Warning: you need to make sure the reference is always valid, otherwise this can result in undefined behavior.” So it shouldn’t be surprising that people call out the “No undefined behavior” claim on the home page as dubious.