2015-04-10 16:44:37 -07:00
|
|
|
/* stdint.h */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2014 Wind River Systems, Inc.
|
|
|
|
|
*
|
2017-01-18 17:01:01 -08:00
|
|
|
* SPDX-License-Identifier: Apache-2.0
|
2015-04-10 16:44:37 -07:00
|
|
|
*/
|
|
|
|
|
|
2018-09-14 10:43:44 -07:00
|
|
|
#ifndef ZEPHYR_LIB_LIBC_MINIMAL_INCLUDE_STDINT_H_
|
|
|
|
|
#define ZEPHYR_LIB_LIBC_MINIMAL_INCLUDE_STDINT_H_
|
2015-04-10 16:44:37 -07:00
|
|
|
|
2016-01-22 12:38:49 -05:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
#define INT8_MAX __INT8_MAX__
|
|
|
|
|
#define INT16_MAX __INT16_MAX__
|
|
|
|
|
#define INT32_MAX __INT32_MAX__
|
|
|
|
|
#define INT64_MAX __INT64_MAX__
|
2020-11-05 10:24:33 -06:00
|
|
|
#define INTMAX_MAX __INT64_MAX__
|
2015-04-10 16:44:37 -07:00
|
|
|
|
|
|
|
|
#define INT8_MIN (-INT8_MAX - 1)
|
|
|
|
|
#define INT16_MIN (-INT16_MAX - 1)
|
|
|
|
|
#define INT32_MIN (-INT32_MAX - 1)
|
2018-08-15 16:43:38 -07:00
|
|
|
#define INT64_MIN (-INT64_MAX - 1LL)
|
2015-04-10 16:44:37 -07:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
#define UINT8_MAX __UINT8_MAX__
|
|
|
|
|
#define UINT16_MAX __UINT16_MAX__
|
|
|
|
|
#define UINT32_MAX __UINT32_MAX__
|
|
|
|
|
#define UINT64_MAX __UINT64_MAX__
|
2020-11-05 10:24:33 -06:00
|
|
|
#define UINTMAX_MAX __UINT64_MAX__
|
2015-04-10 16:44:37 -07:00
|
|
|
|
2022-03-08 18:19:53 +01:00
|
|
|
#define INT_FAST8_MAX __INT_FAST8_MAX__
|
|
|
|
|
#define INT_FAST16_MAX __INT_FAST16_MAX__
|
|
|
|
|
#define INT_FAST32_MAX __INT_FAST32_MAX__
|
|
|
|
|
#define INT_FAST64_MAX __INT_FAST64_MAX__
|
|
|
|
|
|
|
|
|
|
#define INT_FAST8_MIN (-INT_FAST8_MAX - 1)
|
|
|
|
|
#define INT_FAST16_MIN (-INT_FAST16_MAX - 1)
|
|
|
|
|
#define INT_FAST32_MIN (-INT_FAST32_MAX - 1)
|
|
|
|
|
#define INT_FAST64_MIN (-INT_FAST64_MAX - 1LL)
|
|
|
|
|
|
|
|
|
|
#define UINT_FAST8_MAX __UINT_FAST8_MAX__
|
|
|
|
|
#define UINT_FAST16_MAX __UINT_FAST16_MAX__
|
|
|
|
|
#define UINT_FAST32_MAX __UINT_FAST32_MAX__
|
|
|
|
|
#define UINT_FAST64_MAX __UINT_FAST64_MAX__
|
|
|
|
|
|
|
|
|
|
#define INT_LEAST8_MAX __INT_LEAST8_MAX__
|
|
|
|
|
#define INT_LEAST16_MAX __INT_LEAST16_MAX__
|
|
|
|
|
#define INT_LEAST32_MAX __INT_LEAST32_MAX__
|
|
|
|
|
#define INT_LEAST64_MAX __INT_LEAST64_MAX__
|
|
|
|
|
|
|
|
|
|
#define INT_LEAST8_MIN (-INT_LEAST8_MAX - 1)
|
|
|
|
|
#define INT_LEAST16_MIN (-INT_LEAST16_MAX - 1)
|
|
|
|
|
#define INT_LEAST32_MIN (-INT_LEAST32_MAX - 1)
|
|
|
|
|
#define INT_LEAST64_MIN (-INT_LEAST64_MAX - 1LL)
|
|
|
|
|
|
|
|
|
|
#define UINT_LEAST8_MAX __UINT_LEAST8_MAX__
|
|
|
|
|
#define UINT_LEAST16_MAX __UINT_LEAST16_MAX__
|
|
|
|
|
#define UINT_LEAST32_MAX __UINT_LEAST32_MAX__
|
|
|
|
|
#define UINT_LEAST64_MAX __UINT_LEAST64_MAX__
|
|
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
#define INTPTR_MAX __INTPTR_MAX__
|
|
|
|
|
#define INTPTR_MIN (-INTPTR_MAX - 1)
|
|
|
|
|
#define UINTPTR_MAX __UINTPTR_MAX__
|
2015-04-10 16:44:37 -07:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
#define PTRDIFF_MAX __PTRDIFF_MAX__
|
|
|
|
|
#define PTRDIFF_MIN (-PTRDIFF_MAX - 1)
|
2015-04-10 16:44:37 -07:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
#define SIZE_MAX __SIZE_MAX__
|
2015-04-10 16:44:37 -07:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
typedef __INT8_TYPE__ int8_t;
|
|
|
|
|
typedef __INT16_TYPE__ int16_t;
|
|
|
|
|
typedef __INT32_TYPE__ int32_t;
|
|
|
|
|
typedef __INT64_TYPE__ int64_t;
|
2020-11-05 10:24:33 -06:00
|
|
|
typedef __INT64_TYPE__ intmax_t;
|
2015-04-10 16:44:37 -07:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
typedef __INT_FAST8_TYPE__ int_fast8_t;
|
|
|
|
|
typedef __INT_FAST16_TYPE__ int_fast16_t;
|
|
|
|
|
typedef __INT_FAST32_TYPE__ int_fast32_t;
|
|
|
|
|
typedef __INT_FAST64_TYPE__ int_fast64_t;
|
2017-08-24 11:22:57 -05:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
typedef __INT_LEAST8_TYPE__ int_least8_t;
|
|
|
|
|
typedef __INT_LEAST16_TYPE__ int_least16_t;
|
|
|
|
|
typedef __INT_LEAST32_TYPE__ int_least32_t;
|
|
|
|
|
typedef __INT_LEAST64_TYPE__ int_least64_t;
|
2017-08-24 11:22:57 -05:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
typedef __UINT8_TYPE__ uint8_t;
|
|
|
|
|
typedef __UINT16_TYPE__ uint16_t;
|
|
|
|
|
typedef __UINT32_TYPE__ uint32_t;
|
|
|
|
|
typedef __UINT64_TYPE__ uint64_t;
|
2020-11-05 10:24:33 -06:00
|
|
|
typedef __UINT64_TYPE__ uintmax_t;
|
2018-06-15 11:28:19 +02:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
typedef __UINT_FAST8_TYPE__ uint_fast8_t;
|
|
|
|
|
typedef __UINT_FAST16_TYPE__ uint_fast16_t;
|
|
|
|
|
typedef __UINT_FAST32_TYPE__ uint_fast32_t;
|
|
|
|
|
typedef __UINT_FAST64_TYPE__ uint_fast64_t;
|
2015-04-10 16:44:37 -07:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
typedef __UINT_LEAST8_TYPE__ uint_least8_t;
|
|
|
|
|
typedef __UINT_LEAST16_TYPE__ uint_least16_t;
|
|
|
|
|
typedef __UINT_LEAST32_TYPE__ uint_least32_t;
|
|
|
|
|
typedef __UINT_LEAST64_TYPE__ uint_least64_t;
|
2017-08-24 11:22:57 -05:00
|
|
|
|
stdint.h: streamline type definitions
Compilers (at least gcc and clang) already provide definitions to
create standard types and their range. For example, __INT16_TYPE__ is
normally defined as a short to be used with the int16_t typedef, and
__INT16_MAX__ is defined as 32767. So it makes sense to rely on them
rather than hardcoding our own, especially for the fast types where
the compiler itself knows what basic type is best.
Using compiler provided definitions makes even more sense when dealing
with 64-bit targets where some types such as intptr_t and size_t must
have a different size and range. Those definitions are then adjusted
by the compiler directly.
However there are two cases for which we should override those
definitions:
* The __INT32_TYPE__ definition on 32-bit targets vary between an int
and a long int depending on the architecture and configuration.
Notably, all compilers shipped with the Zephyr SDK, except for the
i586-zephyr-elfiamcu variant, define __INT32_TYPE__ to a long int.
Whereas, all Linux configurations for gcc, both 32-bit and 64-bit,
always define __INT32_TYPE__ as an int. Having variability here is
not welcome as pointers to a long int and to an int are not deemed
compatible by the compiler, and printing an int32_t defined with a
long using %d makes the compiler to complain, even if they're the
same size on 32-bit targets. Given that an int is always 32 bits
on all targets we might care about, and given that Zephyr hardcoded
int32_t to an int before, then we just redefine __INT32_TYPE__ and
derrivatives to an int to keep the peace in the code.
* The confusion also exists with __INTPTR_TYPE__. Looking again at the
Zephyr SDK, it is defined as an int, even even when __INT32_TYPE__ is
initially a long int. One notable exception is i586-zephyr-elf where
__INTPTR_TYPE__ is a long int even when using -m32. On 64-bit targets
this is always a long int. So let's redefine __INTPTR_TYPE__ to always
be a long int on Zephyr which simplifies the code, works for both
32-bit and 64-bit targets, and mimics what the Linux kernel does.
Only a few print format strings needed adjustment.
In those two cases, there is a safeguard to ensure the type we're
enforcing has the right size and fail the build otherwise.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-06-05 12:19:37 -04:00
|
|
|
typedef __INTPTR_TYPE__ intptr_t;
|
|
|
|
|
typedef __UINTPTR_TYPE__ uintptr_t;
|
2015-04-10 16:44:37 -07:00
|
|
|
|
2024-04-30 14:41:09 +02:00
|
|
|
#if defined(__GNUC__) || defined(__clang__)
|
2020-12-07 10:08:55 -06:00
|
|
|
/* These macros must produce constant integer expressions, which can't
|
|
|
|
|
* be done in the preprocessor (casts aren't allowed). Defer to the
|
|
|
|
|
* GCC internal functions where they're available.
|
|
|
|
|
*/
|
|
|
|
|
#define INT8_C(_v) __INT8_C(_v)
|
|
|
|
|
#define INT16_C(_v) __INT16_C(_v)
|
|
|
|
|
#define INT32_C(_v) __INT32_C(_v)
|
|
|
|
|
#define INT64_C(_v) __INT64_C(_v)
|
|
|
|
|
#define INTMAX_C(_v) __INTMAX_C(_v)
|
|
|
|
|
|
|
|
|
|
#define UINT8_C(_v) __UINT8_C(_v)
|
|
|
|
|
#define UINT16_C(_v) __UINT16_C(_v)
|
|
|
|
|
#define UINT32_C(_v) __UINT32_C(_v)
|
|
|
|
|
#define UINT64_C(_v) __UINT64_C(_v)
|
|
|
|
|
#define UINTMAX_C(_v) __UINTMAX_C(_v)
|
2024-04-30 14:41:09 +02:00
|
|
|
#endif /* defined(__GNUC__) || defined(__clang__) */
|
2020-12-07 10:08:55 -06:00
|
|
|
|
2021-04-29 17:35:28 +08:00
|
|
|
#ifdef __CCAC__
|
|
|
|
|
#ifndef __INT8_C
|
|
|
|
|
#define __INT8_C(x) x
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef INT8_C
|
|
|
|
|
#define INT8_C(x) __INT8_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __UINT8_C
|
|
|
|
|
#define __UINT8_C(x) x ## U
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef UINT8_C
|
|
|
|
|
#define UINT8_C(x) __UINT8_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __INT16_C
|
|
|
|
|
#define __INT16_C(x) x
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef INT16_C
|
|
|
|
|
#define INT16_C(x) __INT16_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __UINT16_C
|
|
|
|
|
#define __UINT16_C(x) x ## U
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef UINT16_C
|
|
|
|
|
#define UINT16_C(x) __UINT16_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __INT32_C
|
|
|
|
|
#define __INT32_C(x) x
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef INT32_C
|
|
|
|
|
#define INT32_C(x) __INT32_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __UINT32_C
|
|
|
|
|
#define __UINT32_C(x) x ## U
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef UINT32_C
|
|
|
|
|
#define UINT32_C(x) __UINT32_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __INT64_C
|
|
|
|
|
#define __INT64_C(x) x
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef INT64_C
|
|
|
|
|
#define INT64_C(x) __INT64_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __UINT64_C
|
|
|
|
|
#define __UINT64_C(x) x ## ULL
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef UINT64_C
|
|
|
|
|
#define UINT64_C(x) __UINT64_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __INTMAX_C
|
|
|
|
|
#define __INTMAX_C(x) x
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef INTMAX_C
|
|
|
|
|
#define INTMAX_C(x) __INTMAX_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef __UINTMAX_C
|
|
|
|
|
#define __UINTMAX_C(x) x ## ULL
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef UINTMAX_C
|
|
|
|
|
#define UINTMAX_C(x) __UINTMAX_C(x)
|
|
|
|
|
#endif
|
|
|
|
|
#endif /* __CCAC__ */
|
|
|
|
|
|
2016-01-22 12:38:49 -05:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2018-09-14 10:43:44 -07:00
|
|
|
#endif /* ZEPHYR_LIB_LIBC_MINIMAL_INCLUDE_STDINT_H_ */
|
