r220177 - [modules] Add support for #include_next.
rnk at google.com
Tue Oct 21 13:10:08 PDT 2014
FTR I agree with this approach, I don't see why we should treat these
On Tue, Oct 21, 2014 at 12:35 PM, Aaron Ballman <aaron at aaronballman.com>
> On Tue, Oct 21, 2014 at 11:31 AM, JF Bastien <jfb at chromium.org> wrote:
> >> The compiler has documented sizes for fundamental types which can be
> >> used to define the types in this file. Eg)
> >> typedef signed char int8_t;
> >> typedef short int16_t;
> >> typedef int int32_t;
> >> Nothing says we cannot provide this in similar fashion for our
> >> stdint.h; though, as I pointed out, that could make this file *very*
> >> ugly with a bunch of target-specific #ifs everywhere to ensure the
> >> proper definitions of *int*_t and friends. I can understand not
> >> wanting to do that (especially since the compiler already has this
> >> information internally).
> > The compiler guaranteeing something is different from that guarantee
> > in the language. C and C++ standard libraries like newlib target multiple
> > compilers and can't rely on what LLVM guarantees, so they either have to
> > configure and ask the compiler by compiling a program, or just straight
> > ask the compiler when it provides nice macros.
> Since others seem to be strongly in favor of (2), I will favor it as
> well. I have made commit r220312 which implements (2), and brings the
> MSVC compat bots back to being green.
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits