Skip to content

Conversation

flyfish30
Copy link
Contributor

@flyfish30 flyfish30 commented Apr 8, 2025

fixes #22045
When there has a C pointer of array that type is [*c][2]c_int, the sema can not get a correct element pointer type for this C pointer. For example, there is a C pointer c_ptr: [*c][2]c_int, the type of &c_ptr.*[0] is *c_int, but the sema get a incorrect type that is *[2]c_int.

The root cause is in elemPtrType function, so I made the following modifications to this function:
If the array_ptr_orig is a C pointer of array, and it is to be derefenced, then the pointer is same as the one size zig pointer. So we cast the C pointer to a one size zig pointer.

Copy link
Member

@Vexu Vexu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs a behavior test.

@flyfish30 flyfish30 force-pushed the fix-array-ref-deref branch from bc7b6d8 to afc83a7 Compare April 11, 2025 08:16
@flyfish30
Copy link
Contributor Author

Needs a behavior test.

I had add a "dereference C pointer of array" test case into behavior test.

When there has a C pointer of array that type is `[*c][2]c_int`, the sema
can not get a correct element pointer type for this C pointer. For example,
there is a C pointer `c_ptr: [*c][2]c_int`, the type of `&c_ptr.*[0]` is
`*c_int`, but the sema get a incorrect type that is `*[2]c_int`.

The root cause is in elemPtrType function, so I made the following modifications
to this function:
If the array_ptr_orig is a C pointer, and it is to be derefenced, then the
pointer is same as the one size zig pointer. So we cast the C pointer to a
one size zig pointer.
@flyfish30 flyfish30 force-pushed the fix-array-ref-deref branch from c3a1b47 to c85e958 Compare April 11, 2025 11:22
@alexrp alexrp added this to the 0.14.1 milestone Apr 11, 2025
@alexrp alexrp requested a review from mlugg April 11, 2025 11:24
@flyfish30 flyfish30 requested a review from Vexu April 17, 2025 08:09
var ptr_info = array_ptr_ty_orig.ptrInfo(zcu);
const array_ptr, const array_ptr_ty = if (ptr_info.flags.size == .c) blk_outer: {
const array_ptr_orig_inst = array_ptr_orig.toIndex().?;
const air_tags = sema.air_instructions.items(.tag);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you looking at the instruction instead of the type? Did checking the type not work?

const array_ptr_orig_inst = array_ptr_orig.toIndex().?;
const air_tags = sema.air_instructions.items(.tag);
const array_ptr_tag = air_tags[@intFromEnum(array_ptr_orig_inst)];
break :blk_outer if (array_ptr_tag == .load) blk_inner: {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is there an inner and an outer blk? Did you run into a bug?

@alexrp alexrp removed this from the 0.14.1 milestone Apr 27, 2025
@mlugg
Copy link
Member

mlugg commented Jul 30, 2025

Feedback left unaddressed for >3 months

@mlugg mlugg closed this Jul 30, 2025
@flyfish30
Copy link
Contributor Author

@mlugg This PR had fix the issue #22045 . Please check this PR.

@mlugg
Copy link
Member

mlugg commented Jul 30, 2025

Feedback was submitted by Vexu in April with questions about your implementation / suggested changes, and you never addressed or responded to it. If you are able to resolve that feedback, feel free to re-open the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

zig translate-c Type Propagation Error for Nullable Pointer ([*c]) Dereferencing and Address Calculation in Zig

4 participants