Skip to content
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

C error: function pointer expected #22256

Open
einar-hjortdal opened this issue Sep 18, 2024 · 10 comments
Open

C error: function pointer expected #22256

einar-hjortdal opened this issue Sep 18, 2024 · 10 comments
Labels
Bug This tag is applied to issues which reports bugs. Status: Confirmed This bug has been confirmed to be valid by a contributor. Unit: cgen Bugs/feature requests, that are related to the default C generating backend.

Comments

@einar-hjortdal
Copy link
Contributor

einar-hjortdal commented Sep 18, 2024

Describe the bug

C error: function pointer expected

Reproduction Steps

git clone git@github.com:einar-hjortdal/firebird.git \
&& cd firebird \
&& git checkout ecba31c3cb1a56e80f49599cdee14131547ded38 \
&& v run src/secure_remote_password_test.v

Expected Behavior

No C error

Current Behavior

C error

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.7 263ba23

Environment details (OS name and version, etc.)

V full version: V 0.4.7 ace4e93.263ba23
OS: linux, Linux version 5.14.0-427.33.1.el9_4.x86_64 (mockbuild@pp-el9) (gcc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-43.el9) #1 SMP PREEMPT_DYNAMIC Thu Aug 29 12:00:49 CEST 2024
Processor: 8 cpus, 64bit, little endian, Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

getwd: /home/einar/Documents/projects/vlang/active/firebird
vexe: /home/einar/.local/lib64/v/v
vexe mtime: 2024-09-18 16:47:41

vroot: OK, value: /home/einar/.local/lib64/v
VMODULES: OK, value: /home/einar/.vmodules
VTMP: OK, value: /tmp/v_1001

Git version: git version 2.43.5
Git vroot status: weekly.2024.37-25-g263ba232
.git/config present: true

CC version: cc (GCC) 11.4.1 20231218 (Red Hat 11.4.1-3)
thirdparty/tcc status: thirdparty-linux-amd64 0134e9b9

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.

@einar-hjortdal einar-hjortdal added the Bug This tag is applied to issues which reports bugs. label Sep 18, 2024
@felipensp
Copy link
Member

The problem is the name clashing. See:

Array_u8 string_bytes = firebird__marshal_array_u8(string_bytes(s));

V s.bytes() turns into string_bytes(s) C code, which crashes.

@felipensp felipensp added Status: Confirmed This bug has been confirmed to be valid by a contributor. Unit: cgen Bugs/feature requests, that are related to the default C generating backend. labels Sep 20, 2024
@felipensp
Copy link
Member

@spytheman @medvednikov what do you guys suggest for this cases?

@einar-hjortdal
Copy link
Contributor Author

Is there a workaround I can use in the meantime? Development is stalled because of this error

@Delta456
Copy link
Member

Is there a workaround I can use in the meantime? Development is stalled because of this error

The error is here

fn (mut p WireProtocol) pack_string(s string) {
	string_bytes := marshal_array_u8(s.bytes())
	p.buf = arrays.append(p.buf, string_bytes)
}

Just change string_bytes to strings_bytes_ for now

@Tungsten-180
Copy link

Tungsten-180 commented Sep 23, 2024

@felipensp would adding a default name mangling for user defined variables, functions, types, etc. and a different one for all internal auto generated types be a viable solution? ie. prefixing all user variables and functions with __VU_ and all internal library variables and std library functions with __VI_?

@felipensp
Copy link
Member

@felipensp would adding a default name mangling for user defined variables, functions, types, etc. and a different one for all internal auto generated types be a viable solution? ie. prefixing all user variables and functions with __VU_ and all internal library variables and std library functions with __VI_?

Yeah, I already thought about this approach. What do you think @medvednikov ?

@einar-hjortdal
Copy link
Contributor Author

Why not postfix userland function names with a hash?

@Tungsten-180
Copy link

Tungsten-180 commented Sep 27, 2024

Why not postfix userland function names with a hash?

is there a benefit to a hash over just an int counter like is used for anonymous... I believe structs?

@felipensp
Copy link
Member

Related to issue #17831

@einar-hjortdal
Copy link
Contributor Author

Why not postfix userland function names with a hash?

is there a benefit to a hash over just an int counter like is used for anonymous... I believe structs?

Hashes are more unique, but now I think an int counter is just fine.

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. Status: Confirmed This bug has been confirmed to be valid by a contributor. Unit: cgen Bugs/feature requests, that are related to the default C generating backend.
Projects
None yet
Development

No branches or pull requests

4 participants