[llvm-bugs] [Bug 24754] Possible defect in implementation of clang compiler headers, vis-a-vis include_next

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24754

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Richard Smith <richard-llvm at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150910/a98231f7/attachment.html>