Comment by delian66
3 years ago
> I would encourage you to respond to the actual points raised in my post.
ok, here is the first thing that I noticed, reading your blog post/review.
> No undefined values ... > C allows you to use an uninitialized variable which can result in Undefined Behavior. I’ll assume that’s what this means. ... > Typically, uninitialized values come from a memory allocation that hasn’t been written to. ... > Let’s see if we can get the V compiler to allocate memory for us without writing to it:
fn main() {
a := []&int { len: 1 }
println(a)
}
That program segfaulted in the automatically generated string conversion method for the println() call (you created a 1 element array of pointers, and since each of the elements is initialized to 0, you got a 0 pointer, then println tried to show that, but the automatically generated string conversion method did not check for 0 pointers -> the segfault).
TLDR: the autogenerated string conversion method has a bug, that will be fixed soon.
Ironically, the cause is the opposite of what you intended to show - the memory for the new array was initialized to 0.
I would have appreciated a bug report in https://github.com/vlang/v/issues , that could be properly tracked till resolution, but apparently people these days have an entire month to dedicate on writing a "review" with a "Rules of engagement" section, but do not have 5 minutes to submit a github issue ¯\_(ツ)_/¯ ...
btw, if you instead of the above did:
fn main() {
a := []int { len: 1 }
println(a)
}
the program (printing `[0]`) will have worked correctly.
Edit: I've filed this in https://github.com/vlang/v/issues/14786
Hmm. So the claim article was examining here was "no undefined values", and you point out that the value is actually initialized to 0 and is thus not undefined.
However, the vlang.io page also makes the separate claim (as mentioned in the article) of "no null". But you seem to be saying that the bug in this case was actually a null pointer?
Yes, it is a null pointer, produced by the initialization to 0, as you noticed.
That is the current state - V wants to prevent setting pointers to arbitrary values, including 0, outside of unsafe code, but not all cases are checked yet, and you can get one. For example, you can also still cast numbers to pointers without unsafe{}:
... and that will compile without an error, and produce `0x0`.
You can also search the issues, and find other examples of code, that ultimately produced null pointers.
> ...apparently people these days have an entire month to dedicate on writing a "review" with a "Rules of engagement" section, but do not have 5 minutes to submit a github issue...
You would think that someone taking that long to do an evaluation of claims would reach out to the V developers in some way. Like via bug report, e-mail, discord, or discussion... If a person doesn't want to give the appearance of doing an attack or "hit piece", you would think they would at least create some plausible deniability for themselves, by taking in account the perspective or response of the language developers.
I'm glad you are taking the time to do counter points and add issues on GitHub (https://github.com/vlang/v/issues), as this situation can be turned to being helpful for V. Whatever is in the evaluation that has some validity, can then be corrected or V developers can point how the evaluation was in error or mistaken.