2

If you read through the GNU libs docs, you can see:

Some non-GNU systems fail to support alloca, so it is less portable. However, a slower emulation of alloca written in C is available for use on systems with this deficiency.

How would a C emulation of alloca() look like, assuming VLAs are not available either?

user1095108
  • 14,119
  • 9
  • 58
  • 116
  • In C++ it would be fairly easy but I doubt that you can write a portable `alloca` function in standard C. – Jabberwocky Jul 28 '16 at 09:34
  • Really? Can you please give a hint how you would do it in C++? – user1095108 Jul 28 '16 at 09:36
  • 1
    @user1095108 With C++ you can just use std::shared_ptr<>, I should think. – Williham Totland Jul 28 '16 at 09:37
  • @WillihamTotland Yeah, if you want to allocate from the heap. – user1095108 Jul 28 '16 at 09:38
  • 1
    An *emulation* shall only respect the global interface, I mean automatically free the allocated bloc when returning from current function. A destructor of a local object can do that, and smart pointers like `shared_ptr` or `uniq_ptr` do it automatically. – Serge Ballesta Jul 28 '16 at 09:42
  • [This answer](http://stackoverflow.com/a/714833/3436922) may be of interest to you. – LPs Jul 28 '16 at 09:42
  • VLA are required in one single version of the C standard: C99, and were made optional again in C11. Maybe this sentence was refering the C99 standard. – Serge Ballesta Jul 28 '16 at 09:46
  • You can look at the GNU implementation, it's open source. It is written in C, but not in 100% strictly portable C. This is the first one I've found: ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c – n. m. could be an AI Jul 28 '16 at 09:52

2 Answers2

1

According to what alloca() is

The alloca() function allocates size bytes of space in the stack frame of the caller. This temporary space is automatically freed when the function that called alloca() returns to its caller.

implementation will be platform-specific, and probably compiler should be aware of it, since generated code must respect to non-fixed offsets of locals at stack frame. So if your toolchain has no VLA - you have nothing to do with it.

Sergio
  • 8,099
  • 2
  • 26
  • 52
0

Since you were looking at GNU libc documentation, you might consider how this would be emulated in GCC.

GCC offers the cleanup attribute to allow a cleanup function to be called when a variable falls out of scope.

void foo (void *p) {
    printf("foo: %p\n", p);
}

int main(void) {
    int x __attribute__((cleanup(foo)));
    x = 7;
    printf("%p\n", &x);
    return 0;
}

In the above program, when x falls out of scope, foo() is passed the address of x.

jxh
  • 69,070
  • 8
  • 110
  • 193
  • It is interesting but not very useful, since gcc provides alloca as a builtin. – n. m. could be an AI Jul 28 '16 at 10:29
  • @n.m. Not always. I mean, GCC doesn't always generate inlined code for `alloca`. Which is why GNU libc provides an emulated implementation. – jxh Jul 28 '16 at 10:42
  • The `` header file says: `#ifdef __GNUC__ #define alloca __builtin_alloca`. It may or may not cause the code to be inline. glibc may be compiled by compilers other than gcc. – n. m. could be an AI Jul 28 '16 at 10:48
  • @n.m. If `alloca.h` is not included, linker will choose emulation if flags cause GCC to not inline `alloca()`. – jxh Jul 28 '16 at 11:30
  • `alloca` requires manipulation of the stack pointer on typical implementations. You cannot just call a function from the linker, there has to be some support by the compiler involved (at least it must not reorder allocation of objects on the stack, etc). Also there is a difference in the lifetime of the allocated object compared to automatic variables. – too honest for this site Jul 28 '16 at 12:53
  • @Olaf I guess you didn't see the link in the comments showing how GNU libc implemented the software emulation. – jxh Jul 28 '16 at 15:39
  • @jxh: `malloc` is no aquivalent replacement for `alloca`. For instance, `alloca` typically has a constant and very low run-time overhead (typically it is just a single Assembler instruction). And most systems C is used for don't even have stdlib available, less provide dynamic memory allocation. – too honest for this site Jul 28 '16 at 16:06
  • @Olaf The text in the question already stated the emulation was less efficient. – jxh Jul 28 '16 at 16:09
  • @jxh: Yes, but as I stated, most systems don't provide dynamic memory allocation. There is no emulation then. Correct way would be to use modern C and not to fiddle around with a 27 year old version which lacks other features of modern programming, too (designated initialisers, boolean type, well-defined division behaviour, etc.). – too honest for this site Jul 28 '16 at 16:14
  • @Olaf Even freestanding implementations may emulate dynamic allocation by reserving a portion of memory in a global array. – jxh Jul 28 '16 at 16:20
  • @jxh: Which is actually what `malloc` & friends do. Yes, they can, but they should not and don't if the programmer is halfway sane. Have you ever done embedded systems development bejond Arduino? (No offence, but your comment made me wonder). – too honest for this site Jul 28 '16 at 16:25
  • @Olaf Yes, I have done embedded programming. Even a tightly provisioned system benefits from allowing multiple modules to share memory resources. This would be dynamic allocation. For example, messaging systems may acquire and release message buffers. An emulation could release buffers automatically. – jxh Jul 28 '16 at 16:33
  • @Olaf On hosted implementations, which is the target of the vast majority of C programmers, `malloc` interacts with the OS to acquire memory resources on demand. This is quite different from how the service would be provided on a bare metal program. A kernel just reserves address ranges. – jxh Jul 28 '16 at 16:41
  • Which certaily works well on systems with 256 bytes RAM in total or less ... And no, the vast majority of systems C is used on are bare-metal embedded systems. Alone 8051 still outnumbers x86+ARMv7A etc. by decades. – too honest for this site Jul 28 '16 at 16:46
  • @Olaf I am counting programmers, not processors. A 256 byte system needs a hardware refresh. Cost of RAM is cheaper than the time spent to turn your programmers into contortionists. – jxh Jul 28 '16 at 16:55
  • @jxh: 1) Tell that accounting if you have some 100 mio or more units selling! Industry is not the same as smartphones! OTOH, the software is required to run without weekly updates. Have you checked your mouse lately? Your USB hubs? Your keyboard? The power-controller in your Smartphone? On your mainboard? Your washing machine? Toaster? The controllers of your electrical energy provider? The heat-pump? etc. pp – too honest for this site Jul 28 '16 at 18:15
  • @Olaf If your software only has to read from and write to some registers or process 32 bits from a DMA location, then it doesn't need VLA, let alone dynamic allocation. Low powered devices have different requirements than applications, so we are not comparing the same apples with each other. If I need a 1MB table, then 256 bytes won't cut it. I am constantly looking for a smartphone with more RAM BTW. – jxh Jul 28 '16 at 18:38