On Monday, 7 October, 2019 14:58, Dominique Pellé <dominique.pe...@gmail.com> wrote:
>Here the allocated size is fixed (always 64 pointers), so alloca does >not seem needed. >I wonder how many other functions could avoid dynamic allocation >like this one (either with a stack array or alloca). Probably a lot. I would note that it probably does not allocate on the stack by default because SQLite3 is intended to be cross-platform. While many Operating Systems and Platforms may allow for lots of stack (virtually unlimited for modern flat address space Operating Systems running on x86_64 hardware), this is not necessarily the case for all Operating Systems or platforms in which the per-thread or per-process stack may be quite limited. For example, in a single-thread process on a "flat virtual address space" machine, the stack theoretically extends from the end of the last code segment all the way up to the bottom of the heap (the heap grows down and the stack grows up). However, as soon as you allow multiple threads in that process, you now have an arbitrary constrained stack, since the threads must each now be allocated a specific address space range for that threads stack. If the memory model is not "flat", then the problem won't exist because the additional thread will merely be allocated a different "selector" for its stack. However, not all machines treat segments as selectors, so there may very well still be constraints (ie, consider the old 16-bit addressing mode the segments/selectors were really just paragraph addresses in a flat address space, not true selectors). -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
