Return to Answer

A few other things that weren't mentioned:

Your code is very Windows specific. I would like to test on my mac though ;). If you are up for it, maybe you can make it portable by replacing the Win sys calls with ANSI color escape codes. See this and this. Or maybe switch to a more powerful library such as ncurses.

Other details:

• Use of VLA in char buff[strlen(nodes)];. This is considered poor practice by some, as it can be a source of stack overflows. Consider using a dynamic buffer acquired with malloc().

• You need to be more consistent with your naming and code layout. You have some names in a tightlypacked notation, e.g.: chrtodigit, and others using snake_case, e.g: splice_away. I suggest sticking to the latter, as it seems more readable. Also, the declaration of write_ui() was split in 3 lines, one for the return type, one for the name and the arg list in its own line. Other functions don't follow this convention. Style consistency is quite important. It helps the "human compiler" process the code.

• Why exactly did you return 1 from main()? It should return zero or nothing on success. Any other value is to indicate an error with the program.

• Long lines were already mentioned. That is a common source of confusion and possibly bugs. You should aim at an 80 columns soft limit and 120 cols hard limit. That is my personal metric.

A few other things that weren't mentioned:

Your code is very Windows specific. I would like to test on my mac though ;). If you are up for it, maybe you can make it portable by replacing the Win sys calls with ANSI color escape codes. See this and this. Or maybe switch to a more powerful library such as ncurses.

Other details:

• Use of VLA in char buff[strlen(nodes)];. This is considered poor practice by some, as it can be a source of stack overflows. Consider using a dynamic buffer acquired with malloc().

• You need to be more consistent with your naming and code layout. You have some names in a tightlypacked notation, e.g.: chrtodigit, and others using snake_case, e.g: splice_away. I suggest sticking to the latter, as it seems more readable. Also, the declaration of write_ui() was split in 3 lines, one for the return type, one for the name and the arg list in its own line. Other functions don't follow this convention. Style consistency is quite important. It helps the "human compiler" process the code.

• Why exactly did you return 1 from main()? It should return zero or nothing on success. Any other value is to indicate an error with the program.

• Long lines were already mentioned. That is a common source of confusion and possibly bugs. You should aim at an 80 columns soft limit and 120 cols hard limit. That is my personal metric.