alloca

Is it possible to predict a stack overflow in C on Linux?

由 倾然丶 夕夏残阳落幕 提交于 2020-07-29 18:57:29
问题 There are certain conditions that can cause stack overflows on an x86 Linux system: struct my_big_object[HUGE_NUMBER] on the stack. Walking through it eventually causes SIGSEGV . The alloca() routine (like malloc() , but uses the stack, automatically frees itself, and also blows up with SIGSEGV if it's too big). Update: alloca() isn't formally deprecated as I originally stated; it is merely discouraged . Is there a way to programmatically detect if the local stack is big enough for a given

Is it possible to predict a stack overflow in C on Linux?

由 放肆的年华 提交于 2020-07-29 18:57:15
问题 There are certain conditions that can cause stack overflows on an x86 Linux system: struct my_big_object[HUGE_NUMBER] on the stack. Walking through it eventually causes SIGSEGV . The alloca() routine (like malloc() , but uses the stack, automatically frees itself, and also blows up with SIGSEGV if it's too big). Update: alloca() isn't formally deprecated as I originally stated; it is merely discouraged . Is there a way to programmatically detect if the local stack is big enough for a given

Is alloca completely replaceable?

由 醉酒当歌 提交于 2020-01-01 09:07:33
问题 I've read quite a few places that alloca is obsolete and should not be used and Variable Length Arrays should be used instead. My question is this: Is alloca completely replaceable by variable length arrays? In my particular instance I have something that looks like this: typedef struct { int *value; size_t size; } some_type; void SomeExternalFunction(some_type); ... void foo(){ //What I thought to do some_type bar; bar.value=alloca(sizeof(int)*10); SomeExternalFunction(bar); //what should be

Is a goto in alloca's function scope valid?

由 浪子不回头ぞ 提交于 2019-12-23 07:29:26
问题 The C standard prohibits a goto into a function scope where a VLA exists. A VLA and the call to alloca function should have the same result on low level. (I could be wrong, as I'm just a C, not a low level programmer, but in my imagin that appears to be witty) So will the following snippet be also undefined behaivng? int main() { char *p; goto label1; { p = _alloca(1); label1: p = NULL; } } Ofcourse I cant refference p , but whats about the behaviour? 回答1: Actually, the rule 6.8.6.1 states: A

alloc, malloc, and alloca — What's the difference?

由 别等时光非礼了梦想. 提交于 2019-12-20 09:35:46
问题 I was under the impression that alloc in Objective-C (when we invoke [anyObject alloc] is actually implementing C function malloc and the memory getting allocated in heap, but could not find anywhere the answer for this. Also, while searching for alloc , I found alloca which allocates memory in stack. If I am not wrong, alloc allocates memory in heap to create objects. So, what is the difference between alloc and malloc (and alloca )? Can anyone please summarize? 回答1: alloc() is not a

Allocation of variable-sized class

由 给你一囗甜甜゛ 提交于 2019-12-12 18:23:20
问题 I have a variable length data structure, a multi-dimensional iterator: class Iterator { public: static Iterator& init(int dim, int* sizes, void* mem) { return *(new (mem) Iterator(dim, sizes)); } static size_t alloc_size(int dim) { return sizeof(Iterator) + sizeof(int) * 2 * dim; } void operator++() { // increment counters, update pos_ and done_ } bool done() const { return done_; } bool pos() const { return pos_; } private: Iterator(int dim, int* sizes) : dim_(dim), pos_(0), done_(false) {

returning alloca pointer

由 感情迁移 提交于 2019-12-11 15:17:39
问题 Does this code return an invalid reference to a variable allocated on the stack? Or what: void *f(size_t sz) { return alloca(sz); } Or is it a special case that is handled by the alloca implementation / compiler support like f(alloca(size), alloca(size)) would be? 回答1: alloca allocates space in the stack frame of f . You can't do anything useful with it once the function returns (it's not "reserved" anymore). The alloca() function allocates size bytes of space in the stack frame of the caller

What's up with gcc's handling of alloca?

由 心不动则不痛 提交于 2019-12-07 16:25:14
问题 On most platforms, alloca just boils down to an inline adjustment of the stack pointer (for example, subtracting from rsp on x64, plus a bit of logic to maintain stack alignment). I was looking at the code that gcc generates for alloca and it is pretty weird. Take the following simple example 1 : #include <alloca.h> #include <stddef.h> volatile void *psink; void func(size_t x) { psink = alloca(x); } This compiles to the following assembly at -O2 : func(unsigned long): push rbp add rdi, 30 and

Stack allocation in function wrapper / alloca in function

由 与世无争的帅哥 提交于 2019-12-07 11:26:16
问题 I'm looking for a way to wrap stack allocations in abstract data types. For example, I'd like to have a vector which can work strictly via allocations on the stack. My biggest hurdle of course is that alloca works only within the current stack frame -- thus I don't see an easy way to wrap this into a function. So far the only way I see to do this is by using macro-like functions which are guaranteed to be compiled into a given stack frame. I don't like this approach since it isn't as type

What's up with gcc's handling of alloca?

由 隐身守侯 提交于 2019-12-05 19:52:27
On most platforms, alloca just boils down to an inline adjustment of the stack pointer (for example, subtracting from rsp on x64, plus a bit of logic to maintain stack alignment). I was looking at the code that gcc generates for alloca and it is pretty weird. Take the following simple example 1 : #include <alloca.h> #include <stddef.h> volatile void *psink; void func(size_t x) { psink = alloca(x); } This compiles to the following assembly at -O2 : func(unsigned long): push rbp add rdi, 30 and rdi, -16 mov rbp, rsp sub rsp, rdi lea rax, [rsp+15] and rax, -16 mov QWORD PTR psink[rip], rax leave
订阅 alloca