On Sat, Apr 21, 2018 at 01:30:55PM +0000, Cym13 via Digitalmars-d-learn wrote:
> On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote:
[...]
> > Unbounded allocation on stack is kind of anti-pattern and a potential DoS vector.
> 
> I'm having trouble seeing how unbounded heap allocations aren't equally a potential DoS vector.
[...]

Generally speaking, the heap is much bigger than the stack (often many times so) and so is less prone to overflow.  Though it's true, it still does happen if you just blindly allocate memory based on unsanitized external input.


T

-- 
My program has no bugs! Only unintentional features...

On Saturday, 21 April 2018 at 13:54:14 UTC, H. S. Teoh wrote:
> On Sat, Apr 21, 2018 at 01:30:55PM +0000, Cym13 via Digitalmars-d-learn wrote:
>> On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote:
> [...]
>> > Unbounded allocation on stack is kind of anti-pattern and a potential DoS vector.
>> 
>> I'm having trouble seeing how unbounded heap allocations aren't equally a potential DoS vector.
> [...]
>
> Generally speaking, the heap is much bigger than the stack (often many times so) and so is less prone to overflow.  Though it's true, it still does happen if you just blindly allocate memory based on unsanitized external input.
>
>
> T

Wait, why? Don't they share the same address space and grow in opposite directions?

On Saturday, 21 April 2018 at 13:30:55 UTC, Cym13 wrote:
[...]

Nevermind, forgot that shared libraries are put between the two.

On Saturday, 21 April 2018 at 13:30:55 UTC, Cym13 wrote:
> On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote:
>> On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
>>> Does D have some way to dynamically allocate on the stack?  I'm looking for something roughly equivalent to the following C code.
>>>
>>> int doSomething(size_t len)
>>> {
>>>     char stackBuffer[len + 1];
>>>     doSomethingElse(stackBuffer);
>>> }
>>>
>>
>> Unbounded allocation on stack is kind of anti-pattern and a potential DoS vector.
>
> I'm having trouble seeing how unbounded heap allocations aren't equally a potential DoS vector.

I could see what you meant, but really stack is typically far more limited then heap in size.

Unless you tune the stack size yourself (i.e. you both build an app and control the environment) there is no sensible way to know the size you can use. It’s also heavily platform dependent.

With heap it’s usually far less limited resource.

Lastly Fibers usually have small stacks.

>
>> A separate region allocator is exactly as fast and can easily survive across boundaries of function calls.
>
> I guess if OP wants it on the stack it's because it doesn't need to survive across boundaries of function calls so this buys nothing in this case.

Yet nothing to lose and much safer bet in general.

In general, I’d expect performance to be the goal here. If so then zone/region allocation is a well known pattern that is not restricted to individual arrays and is widely used in games and industry-grade stuff like browsers/VMs.

>
>> Also you probably want something like char[X] = void;
>>  for efficiency if allocating on stack.
>>
>>> Thanks,
>>> Mike

On 4/21/18 3:57 AM, Uknown wrote:
> On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
>> Does D have some way to dynamically allocate on the stack?  I'm looking for something roughly equivalent to the following C code.
>>
>> int doSomething(size_t len)
>> {
>>     char stackBuffer[len + 1];
>>     doSomethingElse(stackBuffer);
>> }
>>
> 
> The language itself doesn't have something, but you could use `alloca`:

alloca is an intrinsic, and part of the language technically -- it has to be.

Mike, alloca is what you are looking for.

-Steve

On Saturday, 21 April 2018 at 14:25:58 UTC, Cym13 wrote:
> On Saturday, 21 April 2018 at 13:54:14 UTC, H. S. Teoh wrote:
>> On Sat, Apr 21, 2018 at 01:30:55PM +0000, Cym13 via Digitalmars-d-learn wrote:
>>> On Saturday, 21 April 2018 at 12:08:09 UTC, Dmitry Olshansky wrote:
>> [...]
>>> > Unbounded allocation on stack is kind of anti-pattern and a potential DoS vector.
>>> 
>>> I'm having trouble seeing how unbounded heap allocations aren't equally a potential DoS vector.
>> [...]
>>
>> Generally speaking, the heap is much bigger than the stack (often many times so) and so is less prone to overflow.  Though it's true, it still does happen if you just blindly allocate memory based on unsanitized external input.
>>
>>
>> T
>
> Wait, why? Don't they share the same address space and grow in opposite directions?

That was true more like 25 years ago. Same address space is obviously still true. These days heap is usually not using sbrk which is basically what you describe. Also imagine threads and tell me which stack grows towards which ;)

Heap is allocated with mmap on Posix’es and VirtualAlloc on Windows. Stack is typically fixed limit imposed by ulimit and how it grows is beside the point really.

On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote:

> alloca is an intrinsic, and part of the language technically -- it has to be.

From what I can tell `alloca` is only available in the platform's C standard library (actually for Linux it appears be part of libgcc as `__builtin_alloca`; `alloca` is just and alias for it).  Of course I can use 3rd party libraries like C to do this, but it seems like something useful to have in the language for certain use case and optimizations.  Also, my immediate use case if for bare metal microcontroller programming where I'm intentionally avoid C and looking for a way to do this in idiomatic D.

Mike

On Saturday, 21 April 2018 at 23:47:41 UTC, Mike Franklin wrote:
> On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote:
>
>> alloca is an intrinsic, and part of the language technically -- it has to be.
>
> From what I can tell `alloca` is only available in the platform's C standard library (actually for Linux it appears be part of libgcc as `__builtin_alloca`; `alloca` is just and alias for it).
>  Of course I can use 3rd party libraries like C to do this, but it seems like something useful to have in the language for certain use case and optimizations.  Also, my immediate use case if for bare metal microcontroller programming where I'm intentionally avoid C and looking for a way to do this in idiomatic D.
>
> Mike

As you have discovered alloca is a builtin: this is true for LDC, GDC and DMD, it's true for clang and i suspect most C/C++ compilers.
You're not using the C library version of it, the compiler does the stack space reservation inline for you. There is no way around this.

Use `std.experimental.allocator.building_blocks.Region` with a slice from `alloca`.

or if you just want the memory

scope T[] arr = (cast(T*)alloca(n*T.sizeof))[0 .. n];

On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote:
> alloca is an intrinsic, and part of the language technically -- it has to be.

Why does:

scope c = new C();       // allocate c on stack
scope a = new char[len]; // allocate a via gc?

On Sunday, 22 April 2018 at 01:07:44 UTC, Giles Bathgate wrote:
> On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer wrote:
>> alloca is an intrinsic, and part of the language technically -- it has to be.
>
> Why does:
>
> scope c = new C();       // allocate c on stack
> scope a = new char[len]; // allocate a via gc?

Its a special case for classes. Makes them usable without the GC.