Email z soboty 19 lipca 2025 od Charlesa Forsytha: > languages such as Ada that have dynamically-sized values, including values > returned as unconstrained array types, run a second stack in parallel, > putting the dynamically-sized things on that. i suppose it's similar to > Weinstein and Wulf's QuickFit (one very fast malloc strategy) but with > stacked lifetimes.
Incidentally, this is a bit how gnulib's replacement _C_alloca works, which is very clever and impressive: on every alloca call, it does a plain malloc, but it saves the returned address for internal bookkeeping. And then checks its *own* stack frame, by taking address of a local (auto) variable, and saves it to a static location. It then compares the last saved stack address against the current one, and if it is a less deep call stack, it frees all allocas that were allocated deeper. The first call even uses some basic recursion to check stack growth direction. This is brilliant, because it is very portable and does not require variable length stack frames, while also having (opportunistically) correct semantics (the worst case being a temporaty memory leak, or a serious memory leak if stack frames happen to align perfectly). Then there is also an option of calling alloca(0) periodically at shallow stack depths, or in each function using it, which additionally to the usual meaning of freeing the allocations belonging to the deeper frames, also has the extra meaning of freeing the ones from the current frame. Unfortunately this is incompatible with (ab)using stack allocations for something that is supposed to live ~forever, and functions never returning, just as waserror. So it might be better to just use the heap instead for this particular case. -- Wysłane z mojego urządzenia Sailfish ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcd29ad8a4559a4cf-Mbbf417d95f61f8e40e634ff3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
