nlfiedler / bdsort Goto Github PK

In particular, compare Doug Lea's memory allocator 
(http://g.oswego.edu/dl/html/malloc.html) to see if it can improve runtime 
performance.

There are a set of macros defined in bdsort.h that relate to memory allocation 
(e.g. SMALLOC, SCALLOC, FREE). These perform the usual memory allocation and 
free function calls, in addition to updating global variables to track memory 
usage. These should all be replaced with similar functions that have a static 
struct for keeping track of memory usage. In other words, get rid of some of 
the global variables and let the compiler decide if the functions should be 
inlined or not.

In main.c there are a number of hard-coded file system paths and file names 
that need to be parameterized.

Since we're compiling with C99 support, it's time to replace the uses of 
strtok() with strsep(), which handles empty tokens (i.e. two consecutive 
separators).

When compiling the code with default warnings enabled there are a bunch of 
warnings issued for the bdsort code. Should try to correct as many of these as 
possible.

And then turn on more warnings with -Wall or -Wextra.

C is fine for embedded systems and OS kernels. Everything else should be 
written using a modern language with type safety and automatic memory safety. 
Rust is the obvious choice here.

It should be possible to set up something similar to unit tests for C code, 
which would be a good addition to the bdsort code base.

The bdsort code base needs more comments and a general reformatting of the code 
to improve readability.

David was using XCode but instead it seems better to use a makefile so the code 
can be compiled on the command line.

There are a large number of global variables in the bdsort code. Should try to 
make as many of them not global as possible.

Presently all of the command line arguments processed by main.c are cryptically 
named (e.g. sc, ls, oi). As such, there's no telling what they mean. All of 
them need to be renamed to something at least somewhat self descriptive (e.g. 
rename "oi" to "orderin").

Most of the code lacks explanatory comments, but David has supplied many 
helpful descriptions that should live within the code itself.