Comment by ketzu | Hacker News Reader

Comment by ketzu | Hacker News Reader

Parent Full thread

> 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.

[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

All the issues in the post have already been fixed.

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.

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.

[1] https://news.ycombinator.com/item?id=31947510

[2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

> I read this argument in the issue too. How is that remotely relevant?

How is that remotely irrelevant?

What kind of behavior do you expect?

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?

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?

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.)

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.

If making sure references are valid is left up to the user, it's ridiculous to call this language safe.

> 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.

[1]: https://go.dev/ref/spec#Integer_operators

[2]: https://news.ycombinator.com/item?id=31948144

[3]: https://github.com/vlang/v/issues/11059

Reply on news.ycombinator.com