diff mbox series

docs/misra: document the expected sizes of integer types

Message ID alpine.DEB.2.22.394.2403131622020.853156@ubuntu-linux-20-04-desktop (mailing list archive)
State Superseded
Headers show
Series docs/misra: document the expected sizes of integer types | expand

Commit Message

Stefano Stabellini March 13, 2024, 11:23 p.m. UTC
Xen makes assumptions about the size of integer types on the various
architectures. Document these assumptions.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
---
 docs/misra/C-language-toolchain.rst | 44 +++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

Comments

Jan Beulich March 14, 2024, 7:36 a.m. UTC | #1
On 14.03.2024 00:23, Stefano Stabellini wrote:
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.

This all reads as if we required exact widths. Is that really the case? Imo
we e.g. merely depend upon sizeof(int) >= 4 * CHAR_BITS. (I can see that,
while not technically required, we may want to specify CHAR_BITS == 8, at
least for the time being.)

Jan

> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> ---
>  docs/misra/C-language-toolchain.rst | 44 +++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
> index b7c2000992..0d3bb2fe6e 100644
> --- a/docs/misra/C-language-toolchain.rst
> +++ b/docs/misra/C-language-toolchain.rst
> @@ -480,4 +480,48 @@ The table columns are as follows:
>       - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section "11.1 Implementation-defined behavior" of CPP_MANUAL.
>  
>  
> +Sizes of Integer types
> +______________________
> +
> +.. list-table::
> +   :widths: 10 10 45
> +   :header-rows: 1
> +
> +   * - Type
> +     - Size
> +     - Architectures
> +
> +   * - char 
> +     - 8 bits
> +     - all architectures
> +
> +   * - short
> +     - 16 bits
> +     - all architectures
> +
> +   * - int
> +     - 32 bits
> +     - all architectures
> +
> +   * - long
> +     - 32 bits 
> +     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
> +
> +   * - long
> +     - 64 bits 
> +     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
> +
> +   * - long long
> +     - 64-bit
> +     - all architectures
> +
> +   * - pointer
> +     - 32-bit
> +     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
> +
> +   * - pointer
> +     - 64-bit
> +     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
> +
> +
>  END OF DOCUMENT.
George Dunlap March 14, 2024, 9:05 a.m. UTC | #2
On Thu, Mar 14, 2024 at 7:36 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 14.03.2024 00:23, Stefano Stabellini wrote:
> > Xen makes assumptions about the size of integer types on the various
> > architectures. Document these assumptions.
>
> This all reads as if we required exact widths. Is that really the case?

At least one thing here is that *all compilers on the architecture*
need to have the same idea.  If not, we absolutely need to change
"unsigned int" to "uint32_t" in any public interface.

A second thing is not only assumptions about minimum number of bits,
but about storage size and alignment.  Again, if we don't assume that
"unsigned int" is exactly 4 bytes, then we should go through and
change it to "uint32_t" anywhere that the size or alignment matter.

 -George
Stefano Stabellini March 14, 2024, 9:57 p.m. UTC | #3
On Thu, 14 Mar 2024, George Dunlap wrote:
> On Thu, Mar 14, 2024 at 7:36 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 14.03.2024 00:23, Stefano Stabellini wrote:
> > > Xen makes assumptions about the size of integer types on the various
> > > architectures. Document these assumptions.
> >
> > This all reads as if we required exact widths. Is that really the case?
> 
> At least one thing here is that *all compilers on the architecture*
> need to have the same idea.  If not, we absolutely need to change
> "unsigned int" to "uint32_t" in any public interface.

Minor NIT to say "all compilers we intend to support on the
architecture". I am sure there are compilers that don't respect these
assumptions out there but we won't support them.


> A second thing is not only assumptions about minimum number of bits,
> but about storage size and alignment.  Again, if we don't assume that
> "unsigned int" is exactly 4 bytes, then we should go through and
> change it to "uint32_t" anywhere that the size or alignment matter.

Yes, exactly.

Actually I forgot to add the alignment information. I'll do that in the
next version of the patch.
diff mbox series

Patch

diff --git a/docs/misra/C-language-toolchain.rst b/docs/misra/C-language-toolchain.rst
index b7c2000992..0d3bb2fe6e 100644
--- a/docs/misra/C-language-toolchain.rst
+++ b/docs/misra/C-language-toolchain.rst
@@ -480,4 +480,48 @@  The table columns are as follows:
      - See Section "4.13 Preprocessing Directives" of GCC_MANUAL and Section "11.1 Implementation-defined behavior" of CPP_MANUAL.
 
 
+Sizes of Integer types
+______________________
+
+.. list-table::
+   :widths: 10 10 45
+   :header-rows: 1
+
+   * - Type
+     - Size
+     - Architectures
+
+   * - char 
+     - 8 bits
+     - all architectures
+
+   * - short
+     - 16 bits
+     - all architectures
+
+   * - int
+     - 32 bits
+     - all architectures
+
+   * - long
+     - 32 bits 
+     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - long
+     - 64 bits 
+     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+   * - long long
+     - 64-bit
+     - all architectures
+
+   * - pointer
+     - 32-bit
+     - 32-bit architectures (x86_32, ARMv8-A AArch32, ARMv8-R AArch32)
+
+   * - pointer
+     - 64-bit
+     - 64-bit architectures (x86_64, ARMv8-A AArch64, RV64, PPC64)
+
+
 END OF DOCUMENT.