-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Comments
typo in the commit message |
Regarding usage of Currently it is used in 4 places such as the The other 2 current uses of
So instead we'll have to leave the |
I resolved this issue by deleting |
Is there any other way to dynamically allocate memory on the stack? |
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. |
I like the idea of keeping Having a comptime-known upperbound means its just as safe as an array |
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. |
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.The text was updated successfully, but these errors were encountered: