Dennis Guse

ugstdemo.h provides macros such as: ``` #define FIND_PAR_S(p,msg,i,dft) \ { strcpy(i,(argc>p)?argv[p]:dft);\ fprintf(stderr,"%s%s\n",msg,i); } ``` This is neither readable nor easy to debug. Issue #8 is related.

basop/typedef(s).h define basic data types. However, the two files are overly complicated. The general issue is here that these values might affect the results of programs that use these.

Test cases missing / or verification not done

1

Some included programs provide either not test cases or only verification. This includes the following tools / folders: * basop (no tests) * basop/flc (no tests) * eid (no verification)...

Currently, the source files contain a changelog as well as version identifiers in their header. Before using GIT (or other version control system), this is quite useful. Using a VCS,...

Code style: remove smart prototypes (ARGS)

1

In the code a smart prototype define is used. This makes the code slightly more complicated and provides (to my knowledge) no real benefit.

Documentation: Use short copyright notice per file instead of full license

1

Is it really necessary to have show a full license in a source file?

Test: file suffixes

1

The test data contains very different, non-standard file endings. According to Simao, these are in line with the individual ITU-T recommendations. At least, I would recommend having a text document...

Exit code

1

All programs require to have a _useful_ return code (ie, EXIT_SUCCESS or EXIT_FAILURE). This is necessary to use programs in scripts and check if a call succeeded or not.

Documentation: single place to document command line interfaces

1

The command line interface is described usually 4(!) times: in code, as print on -h (display usage), in the file header, and in the PDF file. Proper maintenance will be...

Some printf placeholders are not correct for the data type to be printed. This produces a high number of compiler warnings. Probably overlaps with #5.