mirrors
/
musl
mirror of https://git.musl-libc.org/git/musl
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
musl/include/inttypes.h

228 lines
4.4 KiB
C
Raw Normal View History

initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#ifndef _INTTYPES_H
#define _INTTYPES_H
#ifdef __cplusplus
extern "C" {
#endif
remove all remaining redundant __restrict/__inline/_Noreturn defs
2012-09-09 01:14:52 +04:00
#include <features.h>
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#include <stdint.h>
#define __NEED_wchar_t
#include <bits/alltypes.h>
typedef struct { intmax_t quot, rem; } imaxdiv_t;
intmax_t imaxabs(intmax_t);
imaxdiv_t imaxdiv(intmax_t, intmax_t);
use restrict everywhere it's required by c99 and/or posix 2008 to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
2012-09-07 06:44:55 +04:00
intmax_t strtoimax(const char *__restrict, char **__restrict, int);
uintmax_t strtoumax(const char *__restrict, char **__restrict, int);
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
use restrict everywhere it's required by c99 and/or posix 2008 to deal with the fact that the public headers may be used with pre-c99 compilers, __restrict is used in place of restrict, and defined appropriately for any supported compiler. we also avoid the form [restrict] since older versions of gcc rejected it due to a bug in the original c99 standard, and instead use the form *restrict.
2012-09-07 06:44:55 +04:00
intmax_t wcstoimax(const wchar_t *__restrict, wchar_t **__restrict, int);
uintmax_t wcstoumax(const wchar_t *__restrict, wchar_t **__restrict, int);
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#if UINTPTR_MAX == UINT64_MAX
#define __PRI64 "l"
#else
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define __PRI64 "ll"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#endif
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define PRId8 "d"
#define PRId16 "d"
#define PRId32 "d"
#define PRId64 __PRI64 "d"
#define PRIdLEAST8 "d"
#define PRIdLEAST16 "d"
#define PRIdLEAST32 "d"
#define PRIdLEAST64 __PRI64 "d"
#define PRIdFAST8 "d"
#define PRIdFAST16 "d"
#define PRIdFAST32 "d"
#define PRIdFAST64 __PRI64 "d"
#define PRIi8 "i"
#define PRIi16 "i"
#define PRIi32 "i"
#define PRIi64 __PRI64 "i"
#define PRIiLEAST8 "i"
#define PRIiLEAST16 "i"
#define PRIiLEAST32 "i"
#define PRIiLEAST64 __PRI64 "i"
#define PRIiFAST8 "i"
#define PRIiFAST16 "i"
#define PRIiFAST32 "i"
#define PRIiFAST64 __PRI64 "i"
#define PRIo8 "o"
#define PRIo16 "o"
#define PRIo32 "o"
#define PRIo64 __PRI64 "o"
#define PRIoLEAST8 "o"
#define PRIoLEAST16 "o"
#define PRIoLEAST32 "o"
#define PRIoLEAST64 __PRI64 "o"
#define PRIoFAST8 "o"
#define PRIoFAST16 "o"
#define PRIoFAST32 "o"
#define PRIoFAST64 __PRI64 "o"
#define PRIu8 "u"
#define PRIu16 "u"
#define PRIu32 "u"
#define PRIu64 __PRI64 "u"
#define PRIuLEAST8 "u"
#define PRIuLEAST16 "u"
#define PRIuLEAST32 "u"
#define PRIuLEAST64 __PRI64 "u"
#define PRIuFAST8 "u"
#define PRIuFAST16 "u"
#define PRIuFAST32 "u"
#define PRIuFAST64 __PRI64 "u"
#define PRIx8 "x"
#define PRIx16 "x"
#define PRIx32 "x"
#define PRIx64 __PRI64 "x"
#define PRIxLEAST8 "x"
#define PRIxLEAST16 "x"
#define PRIxLEAST32 "x"
#define PRIxLEAST64 __PRI64 "x"
#define PRIxFAST8 "x"
#define PRIxFAST16 "x"
#define PRIxFAST32 "x"
#define PRIxFAST64 __PRI64 "x"
#define PRIX8 "X"
#define PRIX16 "X"
#define PRIX32 "X"
#define PRIX64 __PRI64 "X"
#define PRIXLEAST8 "X"
#define PRIXLEAST16 "X"
#define PRIXLEAST32 "X"
#define PRIXLEAST64 __PRI64 "X"
#define PRIXFAST8 "X"
#define PRIXFAST16 "X"
#define PRIXFAST32 "X"
#define PRIXFAST64 __PRI64 "X"
#define PRIdMAX __PRI64 "d"
#define PRIiMAX __PRI64 "i"
#define PRIoMAX __PRI64 "o"
#define PRIuMAX __PRI64 "u"
#define PRIxMAX __PRI64 "x"
#define PRIXMAX __PRI64 "X"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#define PRIdPTR "ld"
#define PRIiPTR "li"
#define PRIoPTR "lo"
#define PRIuPTR "lu"
#define PRIxPTR "lx"
#define PRIXPTR "lX"
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define SCNd8 "hhd"
#define SCNd16 "hd"
#define SCNd32 "d"
#define SCNd64 __PRI64 "d"
#define SCNdLEAST8 "hhd"
#define SCNdLEAST16 "hd"
#define SCNdLEAST32 "d"
#define SCNdLEAST64 __PRI64 "d"
#define SCNdFAST8 "hhd"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#define SCNdFAST16 "d"
#define SCNdFAST32 "d"
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define SCNdFAST64 __PRI64 "d"
#define SCNi8 "hhi"
#define SCNi16 "hi"
#define SCNi32 "i"
#define SCNi64 __PRI64 "i"
#define SCNiLEAST8 "hhi"
#define SCNiLEAST16 "hi"
#define SCNiLEAST32 "i"
#define SCNiLEAST64 __PRI64 "i"
#define SCNiFAST8 "hhi"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#define SCNiFAST16 "i"
#define SCNiFAST32 "i"
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define SCNiFAST64 __PRI64 "i"
#define SCNu8 "hhu"
#define SCNu16 "hu"
#define SCNu32 "u"
#define SCNu64 __PRI64 "u"
#define SCNuLEAST8 "hhu"
#define SCNuLEAST16 "hu"
#define SCNuLEAST32 "u"
#define SCNuLEAST64 __PRI64 "u"
#define SCNuFAST8 "hhu"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#define SCNuFAST16 "u"
#define SCNuFAST32 "u"
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define SCNuFAST64 __PRI64 "u"
#define SCNo8 "hho"
#define SCNo16 "ho"
#define SCNo32 "o"
#define SCNo64 __PRI64 "o"
#define SCNoLEAST8 "hho"
#define SCNoLEAST16 "ho"
#define SCNoLEAST32 "o"
#define SCNoLEAST64 __PRI64 "o"
#define SCNoFAST8 "hho"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#define SCNoFAST16 "o"
#define SCNoFAST32 "o"
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define SCNoFAST64 __PRI64 "o"
#define SCNx8 "hhx"
#define SCNx16 "hx"
#define SCNx32 "x"
#define SCNx64 __PRI64 "x"
#define SCNxLEAST8 "hhx"
#define SCNxLEAST16 "hx"
#define SCNxLEAST32 "x"
#define SCNxLEAST64 __PRI64 "x"
#define SCNxFAST8 "hhx"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#define SCNxFAST16 "x"
#define SCNxFAST32 "x"
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#define SCNxFAST64 __PRI64 "x"
#define SCNdMAX __PRI64 "d"
#define SCNiMAX __PRI64 "i"
#define SCNoMAX __PRI64 "o"
#define SCNuMAX __PRI64 "u"
#define SCNxMAX __PRI64 "x"
fix a couple issues in the inttypes.h PRI/SCN macros most importantly, the format/scan macros for the [u]int_fast16_t and [u]int_fast32_t types were defined incorrectly assuming these types would match the native word/pointer size. this is incorrect on any 64-bit system; the "fast" types for 16- and 32-bit integers are simply int. another issue which was "only a warning" (despite being UB) is that the choice of "l" versus "ll" was incorrect for 64-bit types on 64-bit machines. while it would "work" to always use "long long" for 64-bit types, we use "long" on 64-bit machines to match what glibc does and what the ABI documents recommend. the macro definitions were probably right in very old versions of musl, but became wrong when we aligned most closely with the 'standard' ABI. checking UINTPTR_MAX is an easy way to get the system wordsize without pulling in new headers. finally, the useless __PRIPTR macro to allow the underlying type of [u]intptr_t to vary has been removed. we are using "long" on all targets, and thankfully this matches what glibc does, so I do not envision ever needing to change it. thus, the "l" has just been incorporated directly in the strings.
2012-12-03 00:18:05 +04:00
#define SCNdPTR "ld"
#define SCNiPTR "li"
#define SCNoPTR "lo"
#define SCNuPTR "lu"
#define SCNxPTR "lx"
initial check-in, version 0.5.0
2011-02-12 08:22:29 +03:00
#ifdef __cplusplus
}
#endif
#endif