<div dir="ltr"><stddef.h>. This one is tricky:<div><br></div><div>1) There's an (undocumented) interface between the C standard library and this header, where the macros __need_ptrdiff_t, __need_size_t, __need_wchar_t, __need_NULL, __need_wint_t request just a piece of this header rather than the whole thing. If we see any of those, just go straight to the underlying header.</div><div><br></div><div>2) We probably don't want <stddef.h> to include <cstddef> (for consistency with other headers), but <stddef.h> must provide a ::nullptr_t (which we don't want <cstddef> to provide). So neither header includes the other. Instead, both include <__nullptr> for std::nullptr_t, and we duplicate the definition of max_align_t between them, in the case where the compiler's <stddef.h> doesn't provide it.</div><div><br></div><div>If you prefer, I could make <stddef.h> include <cstddef> to avoid the duplication of the max_align_t logic.<br></div><div><br></div><div>This patch depends on patch 02.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 3:42 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><setjmp.h>, an easy one. We guarantee a setjmp macro exists even if this header is somehow included from C (the C standard allows that, so it's not worth checking for __cplusplus).</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 3:36 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Split <math.h> out of <cmath>. This is a big change, but the same pattern as the prior ones.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 3:28 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Likewise for <errno.h>, <float.h>, <inttypes.h></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 3:20 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Split <ctype.h> header out of <cctype></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 3:07 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Next: factoring the definition of std::nullptr_t out into a separate file, so that <cstddef> and <stddef.h> can both use it, without <stddef.h> including <cstddef> and without <cstddef> providing a ::nullptr_t like <stddef.h> does.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 3:02 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">LGTM.<br>
<div><div><br>
On Tue, Oct 6, 2015 at 3:58 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
> On Mon, Oct 5, 2015 at 7:10 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:<br>
>><br>
>> EricWF added a comment.<br>
>><br>
>> I think thing change will help us close a number out outstanding bugs. I<br>
>> don't have any fundamental objections to this approach.  However the size of<br>
>> this patch scares me.  I understand the changes are mostly mechanical but<br>
>> their size can hide things. For example has anybody noticed that your<br>
>> internal changes to `<deque>` are in this patch? It would be nice to break<br>
>> this down into more digestible pieces that could be quickly spot checked.<br>
><br>
><br>
> OK. First such patch is attached. It just removes the macro-capturing<br>
> wrapper functions.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>