Incorrect usage of @cImport

[tauoverpi]

The following promotes an incorrect use of @cImport as it runs translate-c twice (once for each call) and results in two separate modules where all composite types do not compare equal as zig doesn't use structural equality. There should only be a single use of @cImport within the project to avoid such conflicts.

zig-book/Chapters/14-zig-c-interop.qmd

Lines 98 to 104 in d9bf342

	const cmath = @cImport({
	@cInclude("math.h");
	});
	const stdio = @cImport({
	@cDefine("_NO_CRT_STDIO_INLINE", "1");
	@cInclude("stdio.h");
	});

Do also note that @cImport will be removed in favour of ziglang/zig#20630

[pedropark99]

Hello @tauoverpi ! First of all, thank you for your comment! Thank you for mentioning the proposal. I was not aware of it.

Now, when you say:

it runs translate-c twice (once for each call) and results in two separate modules where all composite types do not compare equal

I don't understand why this is a problem, could elaborate more? Or point to some part of the official Zig docs that clarifies your point?

[tauoverpi]

tau@framework16 /tmp$ zig test c.zig c.h -lc -I ./
c.zig:8:17: error: not the same
    if (a != b) @compileError("not the same");
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tau@framework16 /tmp$ cat c.zig
const a = @cImport(@cInclude("c.h")).struct_foo_t;
const b = @cImport({
    @cInclude("b.h");
    @cInclude("c.h");
}).struct_foo_t;

test {
    if (a != b) @compileError("not the same");
}
tau@framework16 /tmp$ cat c.h
struct struct_foo_t {
};
tau@framework16 /tmp$ cat b.h 
#define A 1

The main issue is that separate modules end up being generated thus zig sees them as distinct as zig doesn't use structural types outside of tuples. This means that if you have functions from import b which expect to work with data from import a it results in compilation errors upon as a.struct_foo_t and b.struct_foo_t are not seen as the same type. This commonly happens when one tries to use slightly larger dependencies or dependencies which are not fully isolated and share definitions with other libraries as with smaller examples it's easier to avoid such conflicts.

There is a ticket on this but I need to spend more time to search for it another time.

[pedropark99]

Uhmm I see. Thank you very much for the explanation! This needs to be fixed on the book then.

I also made a quick search earlier through the open issues in the zig GitHub Repo, but I was unable to find the issue that cited this problem. Thank you anyway 😉