3 ms·

> Well, when you use a GC, you don't have to figure out where to put the "free" calls. That is precisely why I mentioned alloca(3C): it automatically frees the

by Annatar 11y ago

> Well, when you use a GC, you don't have to figure out where to put the "free" calls. That is precisely why I mentioned alloca(3C): it automatically frees the memory for you, if you do not want to do it yourself. From the Solaris / illumos alloca(3C) manual page: void *alloca(size_t size); The alloca() function allocates size bytes of space in the stack frame of the caller, and returns a pointer to the allocated block. This temporary space is automatically freed when the caller returns. If the allocated block is beyond the current stack limit, the resulting behavior is unde- fined. > (have you ever tried writing a functional program with explicit malloc and free?) I got my start on MOS 6502 / MOS 6510 / MC68000 assembler, so for me making malloc(3C) and free(3C) calls when programming in a functional style is completely normal. I have no problem with that whatsoever.

panic 11y ago
The part where behavior is undefined when you overflow the stack makes alloca difficult to use safely, but it is very nice when you can use it! Did you write your 6502 code with closures, higher-order functions, and so on? My point is that can be hard to figure out when to free an object in this kind of environment, where a value can be captured by multiple closures and may not have a clear owner.
- Annatar 11y ago
  Then either use C and manually manage memory, or use ANSI common LISP, and no problem.
the_why_of_y 11y ago
If the allocated block is beyond the current stack limit, the resulting behavior is unde- fined. And you even quoted the part that hints at why alloca(3C) is so rarely used in practice: you get a pointer result, but you have no way of knowing if it's actually safe to use it.
- Annatar 11y ago
  This should tell one whether the pointer returned by alloca(3C) is safe to use: #include <sys/time.h> #include <sys/resource.h> #include <stdio.h> int main(int argc, char *argv[]) { struct rlimit limit; getrlimit(RLIMIT_STACK, &limit); printf("Stack start at %p, end at %p.\n", &argc, &argc - limit.rlim_cur); return(0); } % cc limit.c -o limit && ./limit Stack start at 0x7fff51094ba8, end at 0x7fff4f094ba8. If the pointer returned by alloca(3C) is within those memory addresses, and does not exceed the bottom (in this example, $7fff4f094ba8), it is safe to use.

by Annatar 11y ago

panic 11y ago

The part where behavior is undefined when you overflow the stack makes alloca difficult to use safely, but it is very nice when you can use it! Did you write your 6502 code with closures, higher-order functions, and so on? My point is that can be hard to figure out when to free an object in this kind of environment, where a value can be captured by multiple closures and may not have a clear owner.

Annatar 11y ago
Then either use C and manually manage memory, or use ANSI common LISP, and no problem.

the_why_of_y 11y ago

If the allocated block is beyond the current stack limit, the resulting behavior is unde- fined. And you even quoted the part that hints at why alloca(3C) is so rarely used in practice: you get a pointer result, but you have no way of knowing if it's actually safe to use it.

Annatar 11y ago
This should tell one whether the pointer returned by alloca(3C) is safe to use: #include <sys/time.h> #include <sys/resource.h> #include <stdio.h> int main(int argc, char *argv[]) { struct rlimit limit; getrlimit(RLIMIT_STACK, &limit); printf("Stack start at %p, end at %p.\n", &argc, &argc - limit.rlim_cur); return(0); } % cc limit.c -o limit && ./limit Stack start at 0x7fff51094ba8, end at 0x7fff4f094ba8. If the pointer returned by alloca(3C) is within those memory addresses, and does not exceed the bottom (in this example, $7fff4f094ba8), it is safe to use.