Can't pass non-nullable pointer to nullable

[tjpalmer]

Seems like this should be allowed as implicitly compatible (of course, not the other way around):

D:\Workspace\beast\src\main.zig:120:34: error: expected type '?&const ?&const u8', found '&const &const u8'
    c.glShaderSource(shader, 1, &sources, &sizes);

[tjpalmer]

Maybe it's the nested pointer risk in case the callee wanted to change things? But they are const in this case, so seems like it should be presumed safe.

[tjpalmer]

Moved some code to a separate file, and then this error popped up, too:

D:\Workspace\beast\src\main.zig:29:29: error: expected type '?&struct_SDL_Window', found '&struct_SDL_Window'
  c.SDL_GL_SwapWindow(window.window);
                            ^
D:\Workspace\beast\src\main.zig:46:39: error: expected type '?&struct_SDL_Window', found '&struct_SDL_Window'
            c.SDL_GL_SwapWindow(window.window);

It wasn't previously causing this error, so something subtle might be going on, and it might be related to the original error report above, since it's about non-null to null, again. And no nested pointers here, so that should be an issue in this case either.

[andrewrk]

I'll get these fixed soon. In the meantime, a workaround is using @ptrCast. It should work even with nullable pointers.

[tjpalmer]

Thanks much. I wasn't fully sure which cast I ought to use. Interestingly enough, this also worked and allowed the later use of &sources without casting:

    const sources: ?&const u8 = &source[0];

And for the second case, switching which file the call was in also worked.

[andrewrk]

Is your code open source by any chance? So that I could try to repro these bugs?

[tjpalmer]

It's in this repo: https://github.com/tjpalmer/beast

The second case above was happening when the code was in main.

[andrewrk]

Thanks! I'll have a look. Unrelated to this bug, one thing I would recommend is to have only a single @cImport in your entire program. The reason for having multiple is advanced, for situations where, in C, you would want to compile different .o files with different preprocessor defines, or something like this.

[tjpalmer]

I had them separate so I could more easily relate dependencies and encapsulate. (This code is also early and on limited time, so don't presume everything there is on purpose, though.) So I understand better, what are the reasons for a single @cImport?

[andrewrk]

I added to the docs to answer this: http://ziglang.org/documentation/master/#cImport