https://llvm.org/bugs/show_bug.cgi?id=24754
Richard Smith <richard-l...@metafoo.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Smith <richard-l...@metafoo.co.uk> --- (In reply to comment #2) > Hardly spelunking. It really is. The existence of these files is an implementation detail of the compiler; we've recently been discussing the possibility of baking them into the compiler and not making them present on the file system at all. > Also, such an implementation would not rely on an extension like > include_next but instead attempt to detect and include the first stdint.h > header otherwise found by the normal search in the include search paths and > roll the normal include chain from there. There's no portable way for it to detect those headers, and as you've seen here, including them does not work portably either (even if they exist as on-disk files and you can figure out a way to include them). The right thing to do is to use #include_next (for the compilers that support it). Note also that your proposed technique doesn't even work: if someone includes your C++ standard library header by an include path (which you seem to be claiming is reasonable), they will include clang's header, whose include_next will include the C++ standard library header (or maybe something even earlier on the include path), and if that header has a normal include guard, we will never reach the C library's header. > Anyways, the point is that (at least) the stdint.h compiler header is > crafted in a way that prevents this use and it seems like an arbitrary > restriction with no other purpose than that. It's not arbitrary and purposeless, it's following the normal include guard idiom. It would be weird if it did anything else. -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ llvm-bugs mailing list llvm-bugs@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs