Data types

[xmfcx]

Follow up from: autowarefoundation/autoware.universe#2234

Autosar

Autosar CPP14 Guidelines: https://www.autosar.org/fileadmin/user_upload/standards/adaptive/21-11/AUTOSAR_RS_CPP14Guidelines.pdf

6.3.9 Types

Rule A3-9-1 (required, implementation, automated)

Fixed width integer types from <cstdint>, indicating the size and signedness, shall be used in place of the basic numerical types.

MISRA

Autosar extends the MISRA-CPP-2008: http://www.tlemp.com/download/rule/MISRA-CPP-2008-STANDARD.pdf

Rule 3–9–2 (Advisory)

typedefs that indicate size and signedness should be used in place of the basic numerical types

The basic numerical types of char, int, short, long, float, double and long double should not be used, but specific-length typedefs should be used.
This rule helps to clarify the size of the storage, but does not guarantee portability because of the asymmetric behaviour of integral promotion.

Example

The ISO (POSIX) typedefs as shown below are recommended and are used for all basic numerical and character types in this document. For a 32-bit integer machine, these are as follows:

typedef char char_t;
typedef signed char int8_t;
typedef signed short int16_t;
typedef signed int int32_t;
typedef signed long int64_t;
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long uint64_t;
typedef float float32_t;
typedef double float64_t;
typedef long double float128_t;

Autoware

In Autoware.Auto, we used to use for integer types and typedefs for floating point types.

https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/blob/master/src/common/autoware_auto_common/include/common/types.hpp#L39

• Should we follow a similar style for Autoware Core?
  • What kind of tools can we use to automate these rules?

cc @kenji-miyake @mitsudome-r @wep21 @isamu-takagi

[kenji-miyake]

@xmfcx Thank you for opening this thread.

In Autoware.Auto, we used to use for integer types and typedefs for floating point types.
Should we follow a similar style for Autoware Core?

I don't think so because in the B.1 Traceability to MISRA C++:2008 section, A3–9–2 is not recommended and is replaced by A3-9-1.

What kind of tools can we use to automate these rules?

Seeing AUTOSAR says Rule M3-9-1 (required, implementation, automated), there is a way to automatically check this rule, but I'm not sure what it is.

Maybe CodeQL can check it?
https://github.com/github/codeql-coding-standards/blob/be885f4c26e54748598900ab760a8826f7d4ce00/rules.csv

[xmfcx]

@kenji-miyake

I don't think so because in the B.1 Traceability to MISRA C++:2008 section, A3–9–2 is not recommended and is replaced by A3-9-1.

In Autosar page 70/514 says:

MISRA C++ 2008 [7]: Rule 3-9-2 typedefs that indicate size and signedness
should be used in place of the basic numerical types.

So for floating type numbers, until C++23 is out and we can use #include <stdfloat> we might need to wrap float and double with float32_t, float64_t.

I've also checked the B.1 Traceability to MISRA C++:2008 section, A3–9–2 part and I see that they updated the old rule because in C++11 <cstdint> came out to replace some part of it.

[kenji-miyake]

@xmfcx For floating-point types, I guess A0-4-1 covers them.

Rule A0-4-1 (required, infrastructure / toolchain, non-automated)
Floating-point implementation shall comply with IEEE 754 standard

So I think we don't need a wrapper for C++23 for now. If we create a wrapper, I guess we can't fully support the feature. (std::float16_t, std::float128_t, and std::bfloat16_t)
I feel it's enough that we reconsider it after C++23 is available with Autoware.

[xmfcx]

So I think we don't need a wrapper for C++23 for now. If we create a wrapper, I guess we can't fully support the feature. (std::float16_t, std::float128_t, and std::bfloat16_t) I feel it's enough that we reconsider it after C++23 is available with Autoware.

I think std::float128_t is long double but rest (std::float16_t, std::bfloat16_t) don't seem to be there (and also not common either).

But I agree that we can postpone floating points to post-C++23 timeline. I also don't like passing these type definitions around with annoying dependencies. Since we don't have MISRA/AUTOSAR compliance requirements for the short term, I think we can postpone it.

@kenji-miyake Do you think we should enforce <cstdint> for all the new code in Autoware Core?

[kenji-miyake]

@xmfcx I think starting from advisory is fine. We can easily replace it later. If we can introduce a linter for the rule, it's good to enforce it.

[xmfcx]

What about handling of:

using bool8_t = bool;
using char8_t = char;
using uchar8_t = unsigned char;

These are not defined in <cstdint>

Any thoughts?

[xmfcx]

It seems https://en.cppreference.com/w/cpp/keyword/char8_t is a part of C++20.

[kenji-miyake]

I think it's enough we enforce the rules after we introduce the automatic check.
So, I mean CI checks should come first for these kinds of issues.
Without that, maintenance costs would extremely increase.