Memmove causing program crashes, giving SIGTRAP in GDB(?)

[KENNON J CONRAD]

That is not going to happen for two reasons.
1.  It would unnecessarily consume more memory.  This test case (Large Text Compression Benchmark by Matt Mahoney) already
uses about 16 GB of memory to run optimally and using more memory may cause (additional?) paging and thrashing on my test machine
that has 16 GB of RAM.
2.  It would likely be slower to execute.  The entire array would need to be copied with up to 3 memcpy's every time the array
is modified, and either copied back with another memcpy or the code would need to manage two start of array pointers.

Efficient code is not janky hanky panky.  The latest release of GLZA uses 16 lines of C code that can be easily reduced to 10 lines
since alignment is apparently not an issue, or slighly more if the "stash and move" method is used like the memmove function does.
Brute forcing it with 3 - 4 memcpy's plus an extra memory allocation with an additional pointer that needs to be passed to and
managed by the thread would likely require more code than that.

> On 02/27/2026 2:17 PM PST matthew patton <pattonme@yahoo.com> wrote:
> 
>  
> do what I suggested in my earlier post.
> 2 copies of the datastructure A and B. you only need to malloc them once at the beginning and also since only one thread manipulates the data, right?
> 
> When you're in a situation where you need to 'slide' the data to the right, just memcpy from the current to the new and offset by the sizeof_int16_t). No janky hanky panky and can't possibly have CPU or OS side-effects.