C pointer checks alignment with @ptrFromInt

[ypsvlq]

Zig Version

0.15.0-dev.905+edf785db0

Steps to Reproduce and Observed Behavior

_ = @as([*c]u64, @ptrFromInt(1)); results in error: pointer type '[*c]u64' requires aligned address

_ = @as([*c]u64, 1); builds successfully.

Expected Behavior

Builds successfully.

[rohlem]

I would assume that for your selected target platform / configuration, @alignOf(u64) > 1.
In that case the compile error is expected/correct behavior.
(But maybe we could/should alter/enhance the error message?)

You can explicitly specify an under-aligned pointer type as f.e. [*c] align(1) u64,
so the declaration becomes const x: [*c] align(1) u64 = @ptrFromInt(1);.
With that change the example compiles correctly for me on zig version 0.15.0-dev.889+b8ac740a1.

[ypsvlq]

The documentation for C pointers says

Does not support Zig-only pointer attributes such as alignment.

which is supported by the ability to assign and compare with ints directly (and I think is the correct choice, as C APIs do not always expect pointer alignment). This came up in win32, which has a number of functions declared as taking pointers that also take certain int values.

[rohlem]

The documentation for C pointers says

Does not support Zig-only pointer attributes such as alignment.

Well, as demonstrated by your code, and my recommendation (tested working for me), the langref is wrong about this, making this a documentation issue.

I don't know about that win32 package,
but I imagine that extern "C" function parameters have a stronger restriction (extern struct may have it as well),
since they are meant to conform to the C ABI, but the C language has no way of specifying pointer alignment separate from the pointee's natural alignment.

[ypsvlq]

There is no restriction in C on the value held in a pointer. Zig types do not work the same, which (I assume) is why you can write const x: [*c]u64 = 1; and it works.

[rohlem]

Ah, seems I misunderstood: So a variable of that type can hold any value / address, even if accessing the pointee would be underaligned (=> undefined behavior in C I think).
That seems unsafe, I assumed that [*c] was primarily about multiplicity and didn't interact with alignment.

But if that's the intended behavior of status-quo, I guess it makes sense for @ptrFromInt to also respect this property.
I'm not sure how combining [*c] with align(N) should behave then. Maybe always be a compile error?
Or maybe [*c] pointers should just default to align(1), but higher alignments could still be allowed as manual assertions/guarantees to the compiler?

EDIT:
On second thought, implicit align(1) introduces a subtle difference in semantics:
C code *T asserts correct alignment, while [*c] align(1) T makes loads and stores safe even if under-aligned.
That means that for complete accuracy, translate-c now needs to use [*c] align(@alignOf(T)) T instead of plain [*c] T. Hand-translating is likely to miss this subtlety.
It would still be a safer default, which aligns with Zig's core design; just something to keep in mind, that should be mentioned in documentation though.

I think the alternative to this would be to document status-quo semantics: [*c]-Pointers allow under-aligned values, but no access to under-aligned pointees.
This would mean that both @ptrFromInt and @ptrCast would have to be aware of this wrinkle.
(I personally don't think the use case of translating C code is quite worth muddying up Zig's pointer semantics like this, so I'd still vote for [*c] defaulting to align(1).)

[ypsvlq]

That seems unsafe

C pointers are less safe, but for their intended use I think ignoring alignment is the right behaviour. It's not a property of C, and there are C APIs that rely on this.

maybe [*c] pointers should just default to align(1), but higher alignments could still be allowed as manual assertions/guarantees to the compiler?

This seems okay to me (although I would think if you are specifying an alignment you would not use a C pointer in the first place, since they seem to primarily exist for translated/generated code).

[vadim-za]

Or maybe [*c] pointers should just default to align(1), but higher alignments could still be allowed as manual assertions/guarantees to the compiler?

@rohlem Second that. Seems most logical to me

Edit: this might also make *c pointers less likely to be misused for pure Zig code (assuming the intention is still being that they should be used only for C-interoperability).

This came up in win32, which has a number of functions declared as taking pointers that also take certain int values.

@ypsvlq See #19560
There are a couple of links to external discussions. In the end I came up to simply specifying 1-aligned pointer types in the respective cases explicitly myself. IIRC the union trick showed up some usability issues, but that was a while ago, I don't remember exactly.

[ypsvlq]

In the end I came up to simply specifying 1-aligned pointer types in the respective cases explicitly myself.

For manually written bindings I think that's the best thing to do. It doesn't seem very useful for C pointers as they can already hold unaligned values (the win32 package I was talking about is a generated file).

[vadim-za]

In the end I came up to simply specifying 1-aligned pointer types in the respective cases explicitly myself.

For manually written bindings I think that's the best thing to do. It doesn't seem very useful for C pointers as they can already hold unaligned values (the win32 package I was talking about is a generated file).

Even though C pointers can hold unaligned values, I don't think it's very common in practice. Normally C data are allocated in a properly aligned fashion, and unaligned pointer values are rather exceptional. But I find it consistent not to impose any alignment on *c pointers, since neither does C/C++ (AFAIK).

[ypsvlq]

It is not common (and is undefined, in C) but there is no enforcement in the type system and there are APIs that rely on this.

[vadim-za]

(the win32 package I was talking about is a generated file)

Considering the status quo of the Zig language, one might suggest that this is a bug in the generator (it must make exceptions for certain calls and data fields).

Edit: this is not the only bug of the kind. E.g. consider marlersoft/zigwin32#6

[ypsvlq]

There is currently no issue using the generated code like this, it just omits @ptrFromInt.

@as([*c]u64, 1) is valid, @as([*c]u64, @ptrFromInt(1)) is not valid, which is what this issue is about.

[vadim-za]

There is currently no issue using the generated code like this, it just omits @ptrFromInt.

@as([*c]u64, 1) is valid, @as([*c]u64, @ptrFromInt(1)) is not valid, which is what this issue is about.

I see now. I'd suggest to edit the issue description, it's a bit misleading IMHO. const x: [*c]u64 = 1; is not the expected behavior (BTW I had no idea that integers coerce to *c pointers without a cast, looks somewhat surprising to me), it's part of the issue description. The expected behavior is that const x: [*c]u64 = @ptrFromInt(1); also builds successfully, IIUC.

[ypsvlq]

I'd suggest to edit the issue description, it's a bit misleading IMHO.

Sure, I guess I didn't consider it relevant to "Steps to Reproduce and Observed Behaviour", but it's clearer like this.

I had no idea that integers coerce to *c pointers without a cast, looks somewhat surprising to me

Neither did I until I noticed ptrFromInt didn't work and realised I had relied on the implicit cast before. The docs mention C pointers can be compared with ints though, and I assume it makes translate-c work better in some edge cases (since C compilers allow int->pointer without a cast).