bits/fcntl-linux.h should be mapped to fcntl.h

[GoogleCodeExporter]

What steps will reproduce the problem?  Give the *exact* arguments passed
to include-what-you-use, and attach the input source file that gives the
problem (minimal test-cases are much appreciated!)
1. Using some defines from bits/fcntl-linux.h

What is the expected output? What do you see instead?
IWYU should suggest to include fcntl.h because bits/fcntl-linux.h contains
#ifndef _FCNTL_H
# error "Never use <bits/fcntl-linux.h> directly; include <fcntl.h> instead."
#endif
http://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h
.html

What version of the product are you using? On what operating system?
3.4, Gentoo Linux

Please provide any additional information below.
I think this header should be mapped by default because bits/fcntl.h and 
bits/fcntl2.h are already mapped.

Original issue reported on code.google.com by hin...@gmail.com on 7 May 2014 at 12:21

[GoogleCodeExporter]

Thanks for the report!

The attached patch should help, could you verify before I commit?

Original comment by kim.gras...@gmail.com on 7 May 2014 at 6:31

Attachments:

• issue131.patch

[GoogleCodeExporter]

I'd like to add more mappings for #error "Never use <foo.h> directly;..." cases 
and I see a bunch of such files in sysdeps/unix/sysv/linux.  hinidu, can you 
answer a few Linux-related questions, please?

On the system, where is content of sysdeps/unix/sysv/linux located?  Are all 
headers from sysdeps/unix/sysv/linux installed?

Original comment by vsap...@gmail.com on 7 May 2014 at 8:48

[GoogleCodeExporter]

> The attached patch should help, could you verify before I commit?

Yes, it helps, thank you! Perhaps that mapping should be added to gcc.libc.imp 
too?

Original comment by hin...@gmail.com on 8 May 2014 at 9:22

[GoogleCodeExporter]

> On the system, where is content of sysdeps/unix/sysv/linux located?  Are all 
headers from sysdeps/unix/sysv/linux installed?

I attached file with all headers installed by glibc on my system.
Perhaps only the headers which can be installed on user machine have such 
warnings.

> hinidu, can you answer a few Linux-related questions, please?

Of course, I will be glad to help you as far as possible.

Original comment by hin...@gmail.com on 8 May 2014 at 9:41

Attachments:

• glibc_installed_headers.txt

[GoogleCodeExporter]

I've updated GNU libc file mappings according to libc on Ubuntu 14.04.  It's 
slightly different from libc headers on Gentoo, but I think it doesn't matter 
(for example, there are no bits/auxv.h, bits/mman-linux.h, 
bits/stdlib-bsearch.h on Gentoo).

There are duplicate records, but there were duplicates already.  Personally, it 
is more convenient to have duplicates.  When you update mappings, it is easier 
not to check if there is such mapping in different section.

Note that sys/epoll.h is public unlike sys/poll.h.

<cuchar> is missing in GCC 4.8.2, but it should be there [1], so I've added it 
anyway.  It's public-public mapping so IWYU won't replace uchar.h with cuchar.

I am not sure about <bits/wordsize.h> mapping.  There are alternatives: 
<limits.h>, <net/route.h>, <pthread.h>, <stdint.h>, <sys/cdefs.h>.  
<net/route.h> and <pthread.h> definitely shouldn't provide __WORDSIZE.  
Overall, I have an impression, that __WORDSIZE shouldn't be used directly and 
it's unclear which header should provide __WORDSIZE.  I've chosen <limits.h>.  
If you have other ideas, I'll be glad to hear them.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60263

Original comment by vsap...@gmail.com on 9 May 2014 at 4:11

Attachments:

• issue131r2.patch

[GoogleCodeExporter]

I've lost access to a GCC environment to build IWYU, so I can't test there, but 
I'm guessing you've tested with GCC 4.8.2 since you seem to have it.

The MSVC build is happy, so it's a +1 from me, but it would be nice to let 
hinidu confirm that it works there first.

Original comment by kim.gras...@gmail.com on 9 May 2014 at 6:22

[GoogleCodeExporter]

I think <limits.h> is the good header for __WORDSIZE because <limits.h> defines 
CHAR_BIT - number of bits in a char, and <stdint.h> does not have similiar 
defines.
I can confirm that GCC 4.8.2 successfully builds IWYU with issue131r2.patch and 
IWYU seems to work correctly. What else can I do to help?

Original comment by hin...@gmail.com on 9 May 2014 at 7:15

[GoogleCodeExporter]

Thanks everyone for help, committed fix in r543.

hinidu, I've thought I'll need more help with different Linux flavors, but 
Gentoo and Ubuntu differences turned out to be not significant.  Thank you for 
your assistance.

Original comment by vsap...@gmail.com on 10 May 2014 at 2:04

• Changed state: Fixed

[GoogleCodeExporter]

I'm glad that this issue resolved. Thank you for your work!

Original comment by hin...@gmail.com on 10 May 2014 at 7:01