Skip to content

checker: wrapping mutable array in parenthesis circumvents checker #24584

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
4hnme opened this issue May 26, 2025 · 2 comments · May be fixed by #24588
Open

checker: wrapping mutable array in parenthesis circumvents checker #24584

4hnme opened this issue May 26, 2025 · 2 comments · May be fixed by #24588
Assignees
Labels
Bug This tag is applied to issues which reports bugs.

Comments

@4hnme
Copy link

4hnme commented May 26, 2025

Describe the bug

when taking a pointer to an element of a mutable array, adding extra parenthesis sidesteps safety check

Reproduction Steps

mut arr := [1, 2, 3]
mut ptr1 := &(arr[1]) // <- this should error, but it doesn't
mut ptr2 := &arr[1]   // <- this errors, unless put inside unsafe block

Expected Behavior

the checker should catch this

Current Behavior

the checker ignores it

Possible Solution

No response

Additional Information/Context

there's already a check in place for the exact situation, but it is sidestepped with added parenthesis. my attempts at dump debugging show that in this case typ_sym is treated like an immutable value rather than a mutable array

V version

V 0.4.10 52c7130

Environment details (OS name and version, etc.)

V full version V 0.4.10 52c7130
OS linux, "Void Linux"
Processor 4 cpus, 64bit, little endian, Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
Memory 1.11GB/7.74GB
V executable /home/username/thirdparty/v/v
V last modified time 2025-05-26 13:18:58
V home dir OK, value: /home/username/thirdparty/v
VMODULES OK, value: /home/username/.vmodules
VTMP OK, value: /tmp/v_1000
Current working dir OK, value: /home/username/thirdparty/v
Git version git version 2.49.0
V git status weekly.2025.08-533-g52c7130a
.git/config present true
cc version cc (GCC) 14.2.1 20250405
gcc version gcc (GCC) 14.2.1 20250405
clang version clang version 19.1.4
tcc version tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d (x86_64 Linux)
tcc git status thirdparty-linux-amd64 696c1d84
emcc version N/A
glibc version ldd (GNU libc) 2.41

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

@4hnme 4hnme added the Bug This tag is applied to issues which reports bugs. label May 26, 2025
Copy link

Connected to Huly®: V_0.6-22949

@jorgeluismireles
Copy link

Interesting. Seems required unsafe you are mentioning "tries" to protect the mutable array reference and the extra parentheses are doing the same. But using the reference later is more interesting. The reference (does not need to be mutable) can be used as argument of a function where the value referenced can be modified with unsafe de-reference *.

But unsafe de-reference is more powerful than V mutability because the array does not need to be mutable, the reference does not need to be surrounded with unsafe and finally the inmutable array can be mutated.

In next example both arrays mutable a and immutable `b are modified:

fn set_1000(i &int) {
	old := *i
	unsafe{
		*i = 1000
	}
	println('old:${old} new:${*i}')
}

fn main() {
	mut a := [1, 2, 3]
	ref := &(a[1]) // or ref := unsafe{ &a[1] }
	set_1000(ref)
	assert a == [1, 1000, 3]
	
	b := [4, 5, 6] // immutable
	set_1000(&b[1])
	assert b == [4, 1000, 6] // changed though b is immutable
}

An array actually is a reference when passed by, so we can pass mutable arrays for modification or non mutable for only reading.

@Delta456 Delta456 self-assigned this May 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants