> For what it's worth, every GitHub project has a mechanism for submitting issues. It's better Open Source spirit to utilize these tools as intended.
Are project issues the right place for reviews of claims? Negative point sure would be nice to have as github issues (and checking for some easily searchables: they seem to exist [1,2]) but many of the points in the review don't suite issues well. I don't think "you can open tickets" would be a useful response to "wat" [3] either.
Alternatively your suggestion was for me to wade through the issues to figure out if the critizism holds, which I find is not a helpful suggestion either, as many of them are not particularly well searchable. Also, I assumed, as the review got a bit of attention and the creator was in the thread, it would lead to an interesting response a-la "we are aware, fixing it, many fixed already, here is our roadmap" with possible discussion. I am a bit saddened that it turned out to be much more hostile and negative.
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));
}
“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.
> What's wrong with the division by zero issue? It works just like in Go?
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?
I disaggree [1] with your claim that all issues have been fixed, but maybe I misunderstand what "No nulls" means and other things.
> 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.
Not the parent poster, but there seems to be some misunderstanding. The GitHub issue creator explained that they're getting two different behaviors depending on C compile flags. That's already not "the same behavior as Go" AFAIK.
> 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.
> What's wrong with the division by zero issue? It works just like in Go?
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.
Are project issues the right place for reviews of claims? Negative point sure would be nice to have as github issues (and checking for some easily searchables: they seem to exist [1,2]) but many of the points in the review don't suite issues well. I don't think "you can open tickets" would be a useful response to "wat" [3] either.
Alternatively your suggestion was for me to wade through the issues to figure out if the critizism holds, which I find is not a helpful suggestion either, as many of them are not particularly well searchable. Also, I assumed, as the review got a bit of attention and the creator was in the thread, it would lead to an interesting response a-la "we are aware, fixing it, many fixed already, here is our roadmap" with possible discussion. I am a bit saddened that it turned out to be much more hostile and negative.
[1] https://github.com/vlang/v/issues/11059 (won't fix undefined behavior in generated code)
[2] https://github.com/vlang/v/issues/7519 (fixed missing openssl header)
[3] https://www.destroyallsoftware.com/talks/wat