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

give @alloca an upper bound argument and eradicate usage from standard library #225

Closed
andrewrk opened this issue Jan 18, 2017 · 7 comments
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase.
Milestone

Comments

@andrewrk
Copy link
Member

Best practice use of @alloca is to know the upper bound of the size you want to allocate. Let's strongly encourage users to follow this best practice by having alloca have an argument which is the upper bound. Alloca can return an error if the upper bound is violated. Users are free to get the unsafe behavior back by doing %%@alloca(u8, size, upper_bound). This will crash in debug mode and the bounds check will be optimized out in release mode.

@andrewrk andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Jan 18, 2017
@andrewrk
Copy link
Member Author

typo in the commit message

@andrewrk andrewrk reopened this Mar 26, 2017
@andrewrk andrewrk modified the milestone: 0.2.0 Mar 26, 2017
@andrewrk andrewrk modified the milestones: 0.1.0, 0.2.0 Apr 3, 2017
@andrewrk
Copy link
Member Author

andrewrk commented Apr 3, 2017

Regarding usage of @alloca in the standard library, it should be eradicated.

Currently it is used in 4 places such as the open syscall to add a null byte at the end of the provided path: []const u8. In these places, the system requires a null terminated string, and this is the incorrect layer to abstract that. The correct layer is above that. For these I propose that the various ways to open something are given a ?&Allocator parameter. If null is provided then some default bounded stack array is used with a length like 1024, and if the path exceeds this length then error.NameTooLong is returned. Otherwise if an allocator is provided, it can be used to obtain the null terminated string.

The other 2 current uses of @alloca is in bootstrap.zig to convert argv: &?&u8 and envp: &?&u8 to args: [][]u8 and env: []EnvPair. This is problematic because I just checked and the maximum number of command line arguments would cause us to allocate beyond a reasonable stack space (16 MB):

andy@xps ~> getconf ARG_MAX
2097152
andy@xps ~> python3
Python 3.5.3 (default, Jan 17 2017, 07:57:56) 
[GCC 5.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2097152 * 8 / 1024 / 1024
16.0

So instead we'll have to leave the &&u8 in memory, and either 1. use locks and do the conversion to a better format the first time the env var API is accessed, or 2. design the env var API to work with the data in this null terminated format.

@andrewrk andrewrk changed the title give @alloca an upper bound argument give @alloca an upper bound argument and eradicate usage from standard library Apr 3, 2017
andrewrk added a commit that referenced this issue Apr 3, 2017
 * See #204 - zig build system
 * allow builtin types Os, Environ, Arch to be used at runtime.
   they have zero_bits=false and debug info now.
 * Eradicate use of `@alloca` in std for syscalls. See #225
 * add `std.io.writeFile`
 * `std.debug.panic` adds a newline to format
andrewrk added a commit that referenced this issue Apr 3, 2017
See #225

introduce os.EnvMap
@andrewrk
Copy link
Member Author

andrewrk commented Apr 3, 2017

I resolved this issue by deleting @alloca. It's too tempting to use incorrectly.

@ghost
Copy link

ghost commented Feb 8, 2021

Is there any other way to dynamically allocate memory on the stack?

@andrewrk
Copy link
Member Author

andrewrk commented Feb 8, 2021

If you want to dynamically allocate memory, that's what the heap is for. The stack is allocated based on a compile-time-determined upper bound. Dynamically allocating memory on the stack thwarts this, and is therefore not supported by the language.

@marler8997
Copy link
Contributor

marler8997 commented Feb 8, 2021

I like the idea of keeping @alloca with a required "comptime-known" upper bound. Seems like it would be a good middle ground.

Having a comptime-known upperbound means its just as safe as an array [N]T but has the advantage of reducing stack fragmentation which can greatly improve performance in some cases.

@SpexGuy
Copy link
Contributor

SpexGuy commented Feb 9, 2021

We could even always allocate the maximum amount in debug modes, to make sure the upper bound is reasonable. I think this would be helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase.
Projects
None yet
Development

No branches or pull requests

3 participants