In my code, I created a header file that renames some of the default types to abbreviated names. (i.e. uint8_t becomes u8) I used typedef for the declarations and it failed compiling (conflicting declaration 'typedef uint8_t u8'). I've thought of using #define to rename the variables but I hear it's bad practice. What should I do?
You may have a conflict with a library that defines a type named "u8".
EDIT: I get a conflict with "u16" since this is declared in "USBAPI.h" as "typedef unsigned short u16". Enable "verbose ouput" and "show all warnings" for the compiler and you will know more about the conflicts you encounter.
PerryBebbington:
As an aside, what does the _t in uint8_t mean? Why is it not just uint8?
The _t usually wraps an opaque type definition.
POSIX Standard (1003.1) states
B.2.12 Data Types
Defined Types
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.
The types, such as ushort and ulong, which are in common usage, are not defined in POSIX.1-2017 (although ushort_t would be permitted as an extension). They can be added to <sys/types.h> using a feature test macro (see POSIX.1 Symbols). A suggested symbol for these is _SYSIII. Similarly, the types like u_short would probably be best controlled by _BSD.
...
Basically the Standard says that since there are good chances of extending the Standard types' list, the Standard restricts the _t namespace for its own use...
So you are not supposed to do that yourself to avoid conflicts with future versions of Standard C and POSIX, even though many of us do for adding convenience