summaryrefslogtreecommitdiff
path: root/include/inttypes.h
AgeCommit message (Collapse)AuthorFilesLines
2013-10-30fix inttypes.h PRI and SCN macros for [u]intptr_t typesRich Felker1-11/+13
while using "l" unconditionally gave the right behavior due to matching sizes/representations, it was technically UB and produced compiler warnings with format string checking.
2013-05-17remove the __STDC_FORMAT_MACROS nonsense from inttypes.hRich Felker1-4/+0
somehow I missed this when removing the corresponding __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS nonsense from stdint.h. these were all attempts by the C committee to guess what the C++ committee would want, and the guesses turned out to be wrong.
2012-12-02fix a couple issues in the inttypes.h PRI/SCN macrosRich Felker1-22/+25
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-09-08remove all remaining redundant __restrict/__inline/_Noreturn defsRich Felker1-6/+1
2012-09-06use restrict everywhere it's required by c99 and/or posix 2008Rich Felker1-4/+10
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.
2011-02-12initial check-in, version 0.5.0v0.5.0Rich Felker1-0/+227