Proper cast of <string>.str to char *

[ttytm]

Describe the bug

Using .str to cast a string type variable to a C *char results in a compilation error when compiling with (-cc gcc or -cc clang) and -cstrict. Currently, it's required that the programmer writes the typecast &char(<string>.str) explicitly to have it working.

Reproduction Steps

Following uses the layout:

v_with_c_proj
├── c.c
├── c.h
├── main.v
└── v.mod

// c.c
#include "c.h"

void hello(char *str) { printf("Hello %s!\n", str); }

// c.h
#pragma once

#include <stdio.h>

void hello(char *str);

// main.v
import os

#flag -I@VMODROOT
#flag @VMODROOT/c.o

#include "c.h"

fn C.hello(&char)

fn main() {
	arg := os.args[1] or { 'World' }
	C.hello(arg.str)
}

Works

v run .

Errors

v -cc gcc -cstrict run .

Expected Behavior

Works when compiling with mentioned flags.

Current Behavior

builder error:

==================
/tmp/v_1000/project_with_c_code.10712734828064709517.tmp.c: In function ‘main__main’:
/tmp/v_1000/project_with_c_code.10712734828064709517.tmp.c:17770:18: error: pointer targets in passing argument 1 of ‘hello’ differ in signedness 
[-Werror=pointer-sign]
17770 |         hello(arg.str);
      |               ~~~^~~~
      |                  |
      |                  u8 * {aka unsigned char *}
In file included from /tmp/v_1000/project_with_c_code.10712734828064709517.tmp.c:935:
/home/t/Dev/vlang/project_with_c_code/c.h:5:18: note: expected ‘char *’ but argument is of type ‘u8 *’ {aka ‘unsigned char *’}
    5 | void hello(char *str);
      |            ~~~~~~^~~
At top level:
cc1: note: unrecognized command-line option ‘-Wno-excess-initializers’ may have been intended to silence earlier diagnostics
...
==================
(Use `v -cg` to print the entire error message)

builder error: 
==================
C error. This should never happen.

Possible Solution

No response

Additional Information/Context

Might be more of a FR than a bug. Also, I'm not entirely sure what the downsides of an implementation might be, but I'm open to read about them.

V version

-

Environment details (OS name and version, etc.)

V full version: V 0.4.2 48a1d6c
OS: linux, "Manjaro Linux"
Processor: 16 cpus, 64bit, little endian, 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz

getwd: /home/t/Dev/vlang/project_with_c_code
vexe: /home/t/Dev/vlang/v/v
vexe mtime: 2023-10-21 20:32:40

vroot: OK, value: /home/t/Dev/vlang/v
VMODULES: OK, value: /home/t/.vmodules
VTMP: OK, value: /tmp/v_1000

Git version: git version 2.42.0
Git vroot status: weekly.2023.42-19-g48a1d6cc
.git/config present: true

CC version: cc (GCC) 13.2.1 20230801
thirdparty/tcc status: thirdparty-linux-amd64 12f392c3

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.

[shove70]

// main.v
import os

#flag -I@VMODROOT
#flag @VMODROOT/c.o

#include "c.h"

fn C.hello(&i8)       //   ==>   use i8

fn main() {
	arg := os.args[1] or { 'World' }
	C.hello(arg.str)
}

V  i8     =>   C  char
V  u8     =>   C  unsigned char
V  char   =>   C  unsigned char

I think, for now, it's up to the programmer to properly use the corresponding types for V, C interactions

[shove70]

V temporarily does not seem to deal with the type correspondence of V to C

[ttytm]

V temporarily does not seem to deal with the type correspondence of V to C

Yep. But it might be not too hard to add a cast in the cgen if the target type differs like &char in the example.

[shove70]

For C code, V currently does only "insert", not "parse", so the amount of work for this conversion...

[ttytm]

so the amount of work for this conversion...

Not too much 😉

[spytheman]

Currently, it's required that the programmer writes the typecast &char(.str) explicitly to have it working.

Exactly as it should be. Making the V compiler do such conversions automatic, but only in some edge cases, is very brittle, and makes its behavior hard to predict and use.