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

using std.mem.Allocator.noResize in real allocators will leak memory #6460

Open
npaskov opened this issue Sep 29, 2020 · 0 comments
Open

using std.mem.Allocator.noResize in real allocators will leak memory #6460

npaskov opened this issue Sep 29, 2020 · 0 comments
Labels
standard library This issue involves writing Zig code for the standard library.
Milestone

Comments

@npaskov
Copy link

npaskov commented Sep 29, 2020

According to current Allocator convention, calling resizeFn with new_len of 0 must release the memory block.

The noResize function has no knowledge of how to release memory, so if used as suggested, as resizeFn in allocators with no in-place resize ability, it will simply report success and leak the memory.

I would suggest providing explicit Allocator.freeFn for releasing memory, which will provide cleaner set of responsibilities for the Allocator functions and will allow to just have resizeFn==null if allocator does not support in-place resize.

Alternatively, if keeping current Allocator semantics, the noResize function should be removed or hidden, and allocators should always provide resizeFn capable of releasing their own allocated memory.

@daurnimator daurnimator added the standard library This issue involves writing Zig code for the standard library. label Sep 30, 2020
@Vexu Vexu added this to the 0.8.0 milestone Oct 3, 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

No branches or pull requests

4 participants