What's wrong with the division by zero issue? It works just like in Go?
What about the openssl issue? The user didn't install the library on Windows, as was documented.
By the way, we're going to embed openssl to avoid this problem.
$ 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
VV_LOCAL_SYMBOL void main__main(void) {
int x = ((i32)(2147483647)) + 1;
println(int_str(x));
}
Additionally, V’s own documentation calls out a separate instance of undefined behavior (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.
As I understand it, V's emitted C code (in release mode) does not handle the possibility of a divide by zero. As such, according to the C spec, you've now entered territory where literally anything could happen depending on how the compiler or platform is implemented.
Go, alternatively, detects a divide by zero and panics (like V does in debug mode) which will consistently occur regardless of compiler or platform because it is defined behavior.
In the case of the user in the issue, he got a SIGILL but other OSes, compiler versions, architectures, etc. could result in some other outcome entirely.
I'm not familiar with where V is ported to, do all the supported platforms result in the same behavior?
> What's wrong with the division by zero issue?
It is undefined behavior in C. [2] section 6.5.5 the 5th paragraph. V generates code that is undefined behavior in the intermediate language, some people might consider that "undefined behavior".
> It works just like in Go?
I read this argument in the issue too. How is that remotely relevant?
> What about the openssl issue?
I linked issues of things that were mentioned in the initial review. Not issues that were problematic, remarkable or anything else.
[1] https://news.ycombinator.com/item?id=31947510
[2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
How is that remotely irrelevant?
What kind of behavior do you expect?
> What kind of behavior do you expect?
Defined behavior, I assume. If V uses C as an intermediate, and the generated C code invokes undefined behavior, then V can not guarantee "no UB" in that case at all. It is completely up to the C compiler what happens. Even if the compiled app behaves "properly, like Go" with the specific C compiler, with the specific flags, on that specific machine, does not mean this behavior is defined and consistent.
In fact it does not work like in Go, and that's the entire point. In Go, division by zero is well-defined[1]:
If the divisor is zero at run time, a run-time panic occurs.
As pointed out by others[2], divide by zero in C is in contrast explicitly undefined behavior. So the statement "it works just like in Go" is false.
It may do the same thing as Go on your machine, with the C compiler you used on the day that is today. But the fact remains the generated C code produces undefined behavior, and thus this happy accident of yours is entirely irrelevant.
What makes this extra egregious is the fact that "no undefined behavior" is listed as a key feature, and that the relevant issue[3] was closed as wont-fix.
Now, there are several ways to properly fix this.
One is to keep the current behavior and change the wording of the key feature listing to remove "no undefined behavior" or modify it to something like "no additional undefined behavior compared to C".
Another way would be to clearly define the behavior of divide by zero, similar to how Go did. The V transpiler then has to generate extra C code that ensures this well-defined behavior, for example by inserting a check for zero. This should be in place before 1.0 release at least.
[1]: https://go.dev/ref/spec#Integer_operators