struct stat members are implemented through macros and other
stuff, which is defined in that headers, so map the header to the
same headers that struct stat is mapped.
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
siginfo_t members are implemented through macros and other stuff,
which is defined in that header, so map the header to the same
headers that siginfo_t is mapped.
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
SYS_xxx macros, which are implemented in glibc in
<bits/syscall.h>, are intended to be included from
<sys/syscall.h>. See syscall(2), amd also see the following:
$ grepc -k 'SYS_[a-z]\w+' /usr/include | head
/usr/include/x86_64-linux-gnu/bits/syscall.h:35:# define SYS_accept __NR_accept
/usr/include/x86_64-linux-gnu/bits/syscall.h:39:# define SYS_accept4 __NR_accept4
/usr/include/x86_64-linux-gnu/bits/syscall.h:43:# define SYS_access __NR_access
/usr/include/x86_64-linux-gnu/bits/syscall.h:47:# define SYS_acct __NR_acct
/usr/include/x86_64-linux-gnu/bits/syscall.h:51:# define SYS_acl_get __NR_acl_get
/usr/include/x86_64-linux-gnu/bits/syscall.h:55:# define SYS_acl_set __NR_acl_set
/usr/include/x86_64-linux-gnu/bits/syscall.h:59:# define SYS_add_key __NR_add_key
/usr/include/x86_64-linux-gnu/bits/syscall.h:63:# define SYS_adjtimex __NR_adjtimex
/usr/include/x86_64-linux-gnu/bits/syscall.h:67:# define SYS_afs_syscall __NR_afs_syscall
/usr/include/x86_64-linux-gnu/bits/syscall.h:71:# define SYS_alarm __NR_alarm
$ grep -rn bits/syscall.h /usr/include
/usr/include/x86_64-linux-gnu/bits/syscall.h:5:# error "Never use <bits/syscall.h> directly; include <sys/syscall.h> instead."
/usr/include/x86_64-linux-gnu/sys/syscall.h:27: programs expect the traditional form SYS_*. <bits/syscall.h>
/usr/include/x86_64-linux-gnu/sys/syscall.h:29:#include <bits/syscall.h>
I removed duplicate mappings, and also removed the mapping for
<syscall.h>, which is an undocumented feature of glibc. Portable
programs should stick to <sys/syscall.h> (and unportable ones
too, since there's no gain apart from those 4 bytes).
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
IWYU currently warns for this example:
$ cat test.c
#include <inttypes.h>
#include <stdio.h>
int main(void)
{
uint64_t x = UINT64_C(1234);
printf("%" PRIu64 "\n", x);
return 0;
}
$ include-what-you-use test.c
test.c should add these lines:
#include <stdint.h> // for UINT64_C, uint64_t
test.c should remove these lines:
The full include-list for test.c:
#include <inttypes.h> // for PRIu64
#include <stdint.h> // for UINT64_C, uint64_t
#include <stdio.h> // for printf
---
However, the C standard states that "the header <inttypes.h> includes
the header <stdint.h>". So, this program shouldn't need to include
<stdint.h>.
Some mappings were previously added for individual symbols from
<stdint.h> (e.g., commit 24f9fdf0af ("Add more mappings for
[u]intptr_t"), but it's more accurate to export everything. Get rid of
the symbol mappings and add an include mapping.
This makes <time.h> a valid provider of CLOCKS_PER_SEC and other symbols
declared in <bits/time.h>.
Not entirely sure how this fares with older glibc versions, but my
suspicion is <time.h> is a better candidate than <sys/time.h> in the
general case.
Alejandro Colomar