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

Add Compiler Error when returning pointer to stack variable #2646

Open
mbarkhau opened this issue Jun 9, 2019 · 3 comments
Open

Add Compiler Error when returning pointer to stack variable #2646

mbarkhau opened this issue Jun 9, 2019 · 3 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. use case Describes a real use case that is difficult or impossible, but does not propose a solution.
Milestone

Comments

@mbarkhau
Copy link

mbarkhau commented Jun 9, 2019

I'm new to zig and low level programming in general. Naturally when I encountered the code for setting up an allocater I tried to encapsulate it.

    var direct = std.heap.DirectAllocator.init();
    defer direct.deinit();
    var arena = std.heap.ArenaAllocator.init(&direct.allocator);
    defer arena.deinit();

I tried to (in retrospect naively) create a struct to take care of the repetition in my tests:

const MyStruct = struct {
    
    _alloc1: *std.heap.DirectAllocator,
    _alloc2: *std.heap.ArenaAllocator,

    pub fn init() !MyStruct {
        var direct = std.heap.DirectAllocator.init();
        var arena = std.heap.ArenaAllocator.init(&direct.allocator);
        return MyStruct{
            ._alloc1 = &direct,
            ._alloc2 = &arena,
        };
    }
    pub fn deinit(self: MyStruct) void {
        self._alloc2.deinit();
        self._alloc1.deinit();
    }
};

When using this I get a segfault though.

In #zig @shawnl was helpful enough to explain the issue. The allocators are created on the stack of the init function and so the pointers to them that are set on the struct are invalid once the init function returns.

I am opening this issue because @shawnl claims there may be a way to figure out when such pointers are created and survive beyond the lifetime of the stack variables and for the compiler to raise an error.

@andrewrk andrewrk added this to the 0.6.0 milestone Jun 10, 2019
@andrewrk
Copy link
Member

Related: #2301

@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Feb 10, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 30, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 6, 2020
@Vexu Vexu added bug Observed behavior contradicts documented or intended behavior enhancement Solving this issue will likely involve adding new logic or components to the codebase. labels Mar 10, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
@andrewrk andrewrk added proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. use case Describes a real use case that is difficult or impossible, but does not propose a solution. and removed bug Observed behavior contradicts documented or intended behavior enhancement Solving this issue will likely involve adding new logic or components to the codebase. labels Mar 14, 2022
@matu3ba
Copy link
Contributor

matu3ba commented Dec 16, 2022

Closely related: #5725

@Parzival-3141
Copy link
Contributor

Is #2301 still related to this issue? It seems to me that #5725 and this issue are proposing compile-time checks resulting in compile-errors, while #2301 is for runtime safety checks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. use case Describes a real use case that is difficult or impossible, but does not propose a solution.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants