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

[andrewrk]

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]

typo in the commit message

[andrewrk]

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]

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

[ghost]

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

[andrewrk]

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]

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]

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.