vu-programming/copp-skeleton

Project Application Development skeleton for C

copp-skeleton's Issues

The endianness helper function from `util.c` use undefined behaviour

The read_uint32_t function uses undefined behaviour which can be catched by make testsanitizers when running testadvanced2.

By using left shift on the uint8_t it gets promoted to a signed int. If we shift so far that the sign bit can get flipped we get undefined behaviour.

I will submit a pull request for a simple fix which first casts to uint32_t.

Leftover files after make clean

Makefile does not remove all of the created files with make clean. Testadvanced3, and therefore testadvanced and testall, creates a tmp_output file, which remains in the folder even after make clean is used.

Outdated GitLab

The current readme link points to the old GitLab which is not accessible instead of https://vu-oofp.gitlab.io/website/

Task4 testsuite for WIDE are insufficient.

The task4 tests do not test any regular I- prefixed instructions after a WIDE prefixed one. So you don't actually have to reset your compilers WIDE flag to pass the task4 tests.

Names that end with _t are reserved

I'm not certain of the genealogy, but a number of standards align on this and here are a few scattered quotes and references:

Names that end with ‘_t’ are reserved for additional type names.

-From the GNU Reserved Names page

The requirement that additional types defined in this section end in "_t" was prompted by the problem of name space pollution. It is difficult to define a type (where that type is not one defined by POSIX.1-2017) in one header file and use it in another without adding symbols to the name space of the program. To allow implementors to provide their own types, all conforming applications are required to avoid symbols ending in "_t", which permits the implementor to provide additional types. Because a major use of types is in the definition of structure members, which can (and in many cases must) be added to the structures defined in POSIX.1-2017, the need for additional types is compelling.

-From the The Open Group Base Specifications Issue 7

Typedef names beginning with int or uint and ending with _t may be added to the types defined
in the <stdint.h> header. Macro names beginning with INT or UINT and ending with _MAX, _MIN,
or _C may be added to the macros defined in the <stdint.h> header.

-From ISO9899 7.31.10 (Library > Future library directions > Integer types <stdint.h>) which I think I can't link legally

(The clusivity of the "and" in that last one is ambiguous, but I assume it means both names beginning with int/uint and names ending with _t, not just both in combination. I may be wrong.)

...Consequently, renaming word_t and byte_t would be more POSIX-compliant. I'm not sure if that's necessary in this case, but I see a lot of submissions using for instance stack_t, mimicking the typedefs we set, and this might be ingraining a bad habit for students going forward to future projects.