Ptr alignment issue when cImport windows.h

Help
,
1

I have created a win32 window and now I try to set it’s size as follows:

const rect = try getPrimaryMonitorRect();
    c.SetWindowPos(
        self.properties.hwnd,
        c.HWND_TOPMOST,
        rect.left,
        rect.top,
        rect.right - rect.left,
        rect.bottom - rect.top,
        c.SWP_NOZORDER | c.SWP_NOACTIVATE | c.SWP_NOCOPYBITS,
    );

The c namespace contains the cImport of windows.

All calls till now are successfull and a window is created but when calling SetWindowPos it throws the following

error: pointer type ‘[*c]cimport.struct_HWND__’ requires aligned address

zig\zig-windows-x86_64-0.12.0-dev.2334+aef1da163\lib\std\zig\c_translation.zig:13:37: note: called from here
.Pointer => return castToPtr(DestType, SourceType, target),

zig-cache\o\9034f01fdff843fa8c578523b9b2f71e\cimport.zig:56279:63: note: called from here
pub const HWND_TOPMOST = @import(“std”).zig.c_translation.cast(HWND, -@as(c_int, 1));

I tried using @alignCast but got the same issue. I this some weird windows.h quirk that the cImport doesn’t know how to handle? as it basically tries to cast the value -1 to a pointer.

1 Like
2

This seems like C compiler semantics and Zig semantics interacting badly, so the unaligned “address” -1 is accepted by a C compiler but not Zig. There might be a good language-level solution to this, like making all [*c] pointers align(1). I don’t think there’s a good workaround for this except to redefine redeclare the SetWindowPos function:

const WINAPI: std.builtin.CallingConvention = if (@import("builtin").cpu.arch == .x86) .Stdcall else .C;
extern fn SetWindowPos(
    hWnd: c.HWND
    hWndInsertAfter: ?*align(1) c.struct_HWND__,
    x: c_int,
    y: c_int,
    cx: c_int,
    cy: c_int,
    flags: c.UINT,
) callconv(WINAPI) c.BOOL;

The best way for you might be to use the lovely zigwin32.

3 Likes
3

Thanks will try it, I decided to just try the win32 headers as I ran into an issue with zigwin32, reported it but it seems like that project hasn’t been updated for quite a while so not sure wether the project is still active and if that issue will ever be fixed.

4

Might be worth making a PR regenerating with win32gen and pinging marler.

5

Instead of auto-translating windows headers with @cImport, I recommend declaring this function. This way, you can make the function signature whatever you want, and you can make a *anyopaque, or even a usize. You don’t have to do it for every function, just the one that are you giving you problems.

3 Likes
6

I checked the first time when I ran into the issue, it would most likely be resolved by updating a nuget package in the win32 json generator project. unfortunatly I ran into a host of errors when doing it. as it is a large project and did not have the time to dive into it, I mentioned it in the bug report so hopefully it get’s picked up at some point in time. though with the amount of open issues and no responses and long standing open PR’s I’m not sure if anyone is still working on it. So I am a bit afraid of spending quite some time in order to make a pr that then might never be approved.

1 Like