To test files as numbers. Providing both little-&-big endianess modes

By using environment variables, users can change the values of lim_pos and lim_neg persistently, and a future version of the program with --search functionality could use it as memoization/cache

This is perfect for #5

Just like my JS implementation

extremely related to #6 .

Is it possible to accelerate range-search by using multiple cores?

I have 2 implementation ideas (both are essentially the same concept):

Magnitude-based sync. All cores will skip n odd ints, where n is the number of cores. Each core is offset by c, where 0 <= c < n. When the ints they're checking increase in magnitude (1 bit more), each core waits for the other cores to get to the same magnitude level, after that happens, they save the progress to memory (lim_pos & lim_neg) and storage-based cache.

Loop unrolling technique. This works exactly the same as above, but in steps of m, rather than magnitudes. m should be 1 <= m <= 0x100

See this post

For better performance, it should store the table in a file, so the table isn't computed for every call to the program. The file may also store multiple tables (each with a different size). Maybe there should be a directory where each file is its own table.

I don't know where to place these files

This is crucial to have a fast way of checking files or random data from /dev/urandom. It can have a REPL mode for humans, and a "direct" mode for programs