Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault when coercing optional pointers to optional allowzero pointers #3929

Closed
nmichaels opened this issue Dec 16, 2019 · 6 comments
Closed
Labels
bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend.
Milestone

Comments

@nmichaels
Copy link
Contributor

Example code:

test "coerced allowzero" {
    var p: ?* u32 = undefined;
    var q: ?*allowzero u32 = undefined;
    p = @intToPtr(*u32, 4);
    q = p; // segfaults here
}

Note that if either p or q is not optional, there's no issue.

@LemonBoy
Copy link
Contributor

The big problem here is that ir_analyze_cast calls types_match_const_cast_only on the two types at hand,?*T and ?*allowzero T, recursively and concludes that both at the optional-level and at the pointer-level the cast is legal.

Such a cast produces a CastOpNoop that, on the codegen side, simply tries to bitcast the value between the two types without any care about the low-level representation of the two being different.

@andrewrk andrewrk added this to the 0.7.0 milestone Dec 16, 2019
@andrewrk andrewrk added bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend. labels Dec 16, 2019
@JesseRMeyer
Copy link

without any care about the low-level representation of the two being different.

I thought optional pointers were just ordinary pointers under the hood with a bit of compiler-type checking on top? How are their low level representations any different?

@LemonBoy
Copy link
Contributor

I thought optional pointers were just ordinary pointers under the hood with a bit of compiler-type checking on top? How are their low level representations any different?

The idea is to encode the absence of a value with null as it's usually not allowed by pointers... unless you specify allowzero. In that case you cannot pull this trick anymore and the optional type becomes something like this:

const Opt = struct {
   ptr: *allowzero u32,
   empty: u1,
};

@JesseRMeyer
Copy link

@LemonBoy Ah -- Thanks. What is an allowzero optional pointer even supposed to mean, though? As you say, null is how we encode the absence of a value, which by design is, naturally, 0. So why isn't 'empty' above superfluous in general?

@LemonBoy
Copy link
Contributor

What is an allowzero optional pointer even supposed to mean, though?

Not all the address spaces are born equal :) on some systems the zero address is addressable.

@pixelherodev
Copy link
Contributor

Even on x86, zero is addressable - in my Zig-based kernel though, the byte at zero isn't usable because I was running into a segfault - possibly this one, actually - when using allowzero, and I figured one byte wasn't worth it.

@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Aug 13, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 6, 2020
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
Vexu added a commit to Vexu/zig that referenced this issue Dec 28, 2022
Vexu added a commit to Vexu/zig that referenced this issue Dec 28, 2022
Vexu added a commit to Vexu/zig that referenced this issue Dec 28, 2022
Vexu added a commit to Vexu/zig that referenced this issue Dec 28, 2022
Vexu added a commit to Vexu/zig that referenced this issue Dec 28, 2022
Vexu added a commit to Vexu/zig that referenced this issue Dec 29, 2022
@andrewrk andrewrk modified the milestones: 0.12.0, 0.11.0 Dec 29, 2022
TUSF pushed a commit to TUSF/zig that referenced this issue May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend.
Projects
None yet
Development

No branches or pull requests

5 participants