Cxbx-reloaded: Incorrect typedef of fixed-size type

[RadWolfie]

As https://github.com/Cxbx-Reloaded/XbSymbolDatabase/pull/46 points out about fixed-size type to use. I believe Cxbx-Reloaded's src/common/Xbe.h file is not completely following the right way. Such as uint32, uint16, etc when it should be uint32_t, uint16_t, etc. Since compiler will provide proper fixed-size types since C99+ standard from using #include <stdint.h>.

The origin came from src/Cxbx.h file. The more I look at it, the more wrong it is for using "custom" typedef instead of using stdint.h's proper standard.

Using __intXX is Microsoft specific which is also a step backward for cross-platform support.

Sources:

• https://docs.microsoft.com/en-us/cpp/cpp/int8-int16-int32-int64
• https://en.wikipedia.org/wiki/C_data_types

I believe we need to remove both sections of custom typedefs from Cxbx.h file and start using (x)intXX_t typedefs.

The current options I am seeing are...

• Rename all custom typedef variables to correct standard typedef. (multiple file changes)
• Replace only specific custom typedef's defined to use standard typedef (single file change)

[LukeUsher]

I’d prefer to use the types as defined in stdint.h (cstdint for c++) should be used, and the custom types are unnecessary. Using custom typedefs for these sizes was only necessary in c89 before stdint was introduced. Here in 2018, there is not a compiler than does not support stdint

[PatrickvL]

While discussing this, how do we feel about the use of shorter versions of these types: u8, u16, u32, u64, i8, i16, i32, i64, s8, s16, s32 and s64 ?

MAME started using them too, a while ago, see : https://github.com/mamedev/mame/commit/8179a84458204a5e767446fcf7d10f032a40fd0c

[PatrickvL]

Here the declarations in MAME : https://github.com/mamedev/mame/blob/master/src/osd/osdcomm.h#L58

A few discussions on the matter:
https://stackoverflow.com/a/30896945/12170
https://www.linuxjournal.com/article/5783
https://www.reddit.com/r/cpp_questions/comments/7ylwrd/is_it_bad_practice_to_use_typedefs_like_u32_for/
https://doc.rust-lang.org/std/#primitives

BTW : The 'i' prefix refers to integer (implicitly signed), while the 's' prefix is explicitly signed.
The 'u' prefix is obviously for unsigned integers.

Although most people are aware integers are implicitly signed, making that clear by using the 's' prefix is more explicit (but might need some getting used to).

The main reason to use these shorter versions is obviously to need less typing. I'm not sure if that outweighs the need for typedefs, over 'just' using stdint types.

[LukeUsher]

I would much prefer to use stdint wherever possible, I have no real argument other than that's how I've always done things in my own projects. It will work fine with any compiler that supports stdint, and there's no need to worry about other platforms that may have weird integer sizes.

[RadWolfie]

https://stackoverflow.com/a/30896945/12170
https://www.linuxjournal.com/article/5783

These are only for linux standard-ish from linux/types.h header file. Which seems to be used for kernel driver. Plus stackoverflow's comment said linux/types.h are using XintXX_t typedefs for those XintXX, which are meant for linux usage.

https://www.reddit.com/r/cpp_questions/comments/7ylwrd/is_it_bad_practice_to_use_typedefs_like_u32_for/

If you read first comment, which state the code will look less like stock C++.

https://doc.rust-lang.org/std/#primitives

Has nothing to do with C/C++ standard.

I agree with @LukeUsher to use stdint whenever is possible. Using custom typedefs inside our own code alike to Linux or whatever compiler provided while other compiler don't can cause problem with compiling due to duplicated definition either warning or error.

As for mame, I'm not sure where they got linux's shorter name of integer types from.

[PatrickvL]

As much as I dislike typing out needlessly long symbol names, I can see that using widely supported standards is preferred.

[RadWolfie]

For now, let's replace native C/C++ type to stdint for s, i, and u integers. Plus remove name primitive typedefs section. Then perform a "check" if u8/16/32 are defined. If it does exist, do skip custom typedefs.

Doing above method will avoid headache of having problem with compiling for different compiler plus platform specific too.

[LukeUsher]

addressed by #1574