Names that end with _t are reserved

[exegeist]

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 header. Macro names beginning with INT or UINT and ending with _MAX, _MIN, or _C may be added to the macros defined in the header.

-From ISO9899 7.31.10 (Library > Future library directions > Integer types ) 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.

[atzeus]

Good point. It is a bit much to do this now, but is an excellent suggestion for next year.