Having coded #C for a long time (and on platforms that are bit skimpier on resources) I have a special dislike for excessive stack space allocation. Stack space is precious, and gobbling it unnecessarily is the minimum bad style, if not even a bug. If the functions need temporary workspace, and if the area would grow larger than couple of kilobytes in my opinion use of heap is warranted.
One reason to dislike excessive stack size usage is that there are platforms that do not auto-expand the stack on the fly. To cater for excessive stack use you’d have to predefine a huge stack size of the application for no other reason than to cater for the lazy/bad code. Most of the time the stack space would sit unused, only to be truly used when the affected functions are called.
I recently ported Python 3.9.x to #MorphOS and now decided to look into cleaning things up for the port. This involved detecting and patching any excessive stack usage with malloc()ated buffers.
I was somewhat dismayed to spot https://github.com/python/cpython/blob/dc53a3e52a54beef450e4bf451e09b65e0df8043/Modules/_decimal/libmpdec/transpose.c#L179 and https://github.com/python/cpython/blob/dc53a3e52a54beef450e4bf451e09b65e0df8043/Modules/_decimal/libmpdec/transpose.c#L77
Such use of large arrays makes transpose_pow2() utilize 128KB (or 256KB of size_t is 64-bit) of stack space, regardless of the number of rows and columns. Boo, what a waste!
I fixed this by making swap_halfrows_pow2 and squaretrans_pow2 take a pointer to struct that has a union that holds buf1 and buf2 for both functions and then allocating and freeing the buffer in transpose_pow2 as needed.
#development #programming
I feel like I might be older than you, because “a couple of kilobytes” is bigger than the number I expected there. Or maybe it’s that I spent time working on tiny embedded systems way back when.
@[email protected] My first system had 128KB (64KB + banking for the rest), but using C there wasn’t really an option. When I really started to write C more it was on a 1MB system. But depending on situation the acceptable stack usage can indeed be much smaller.
I was just thinking of some weird little handheld POS device from the 1990s, 64kb total or something like that and the OS took up most of it. Can’t remember if it was Aztec or Lattice C… whichever version we had to use it hadn’t quite made it to adopting the ANSI standard yet. Some day maybe I’ll code in C again, it’s so much easier these days.