Rectify our use of std::nullptr_t, inclusions of <stddef.h>/<cstddef>.

Rectify our use of std::nullptr_t, inclusions of <stddef.h>/<cstddef>.

(Convert uses of decltype(nullptr) to std::nullptr_t. Include <cstddef>
where we use std::nullptr_t. Include <stddef.h> for unqualified size_t.)

In general, you want to include <X.h>, not <cX>:

* <cX> need only declare/define things in the std namespace and not
  things in the global namespace (even if in practice it often does).
* (Thus <cX> need not declare/define POSIX extensions declared by <X.h>
  at all, in any namespace.)

So unless you want to write std::size_t, std::fopen(), etc., you want
<X.h>.

A weird case is nullptr_t/std::nullptr_t. C++11 decrees that <stddef.h>
define (::)nullptr_t, even though it's a C++ language feature (note that
it need not define std::nullptr_t at all). So in theory one should be
able to just include <stddef.h> and use nullptr_t (in the global
namespace).

Unfortunately, AFAICT, gcc+libstdc++ and clang+libc++ appear to have
different philosophies here. gcc's <stddef.h> just defines nullptr_t, so
libstdc++ doesn't have its own <stddef.h>. clang's <stddef.h> does NOT
define nullptr_t, so libc++ has its own <stddef.h> that defines
nullptr_t (and which then does an #include_next <stddef.h>, picking up
the compiler's <stddef.h>). Thus including <stddef.h> with
clang+libstdc++ does NOT result in nullptr_t being defined (at least on
Linux currently). :-(

So we use std::nullptr_t and include <cstddef>. Note that sometimes we
also do the right thing and ALSO include <stddef.h> (so that we can use
size_t unqualified).

R=jamesr@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/a6a56396e8ce30e46fa2f391476dcaf586c04344

[jamesr, 2016-01-06 01:07:54]

lgtm

[jamesr, 2016-01-06 01:08:10]

If we run into trouble we can go back to decltype(nullptr)

[viettrungluu, 2016-01-06 21:25:00]

Description was changed from

==========
Rectify our use of std::nullptr_t, inclusions of <stddef.h>/<cstddef>.

(Convert uses of decltype(nullptr) to std::nullptr_t. Include <cstddef>
where we use std::nullptr_t. Include <stddef.h> for unqualified size_t.)

In general, you want to include <X.h>, not <cX>:

* <cX> need only declare/define things in the std namespace and not
  things in the global namespace (even if in practice it often does).
* (Thus <cX> need not declare/define POSIX extensions declared by <X.h>
  at all, in any namespace.)

So unless you want to write std::size_t, std::fopen(), etc., you want
<X.h>.

A weird case is nullptr_t/std::nullptr_t. C++11 decrees that <stddef.h>
define (::)nullptr_t, even though it's a C++ language feature (note that
it need not define std::nullptr_t at all). So in theory one should be
able to just include <stddef.h> and use nullptr_t (in the global
namespace).

Unfortunately, AFAICT, gcc+libstdc++ and clang+libc++ appear to have
different philosophies here. gcc's <stddef.h> just defines nullptr_t, so
libstdc++ doesn't have its own <stddef.h>. clang's <stddef.h> does NOT
define nullptr_t, so libc++ has its own <stddef.h> that defines
nullptr_t (and which then does an #include_next <stddef.h>, picking up
the compiler's <stddef.h>). Thus including <stddef.h> with
clang+libstdc++ does NOT result in nullptr_t being defined (at least on
Linux currently). :-(

So we use std::nullptr_t and include <cstddef>. Note that sometimes we
also do the right thing and ALSO include <stddef.h> (so that we can use
size_t unqualified).

R=jamesr@chromium.org
==========

to

==========
Rectify our use of std::nullptr_t, inclusions of <stddef.h>/<cstddef>.

(Convert uses of decltype(nullptr) to std::nullptr_t. Include <cstddef>
where we use std::nullptr_t. Include <stddef.h> for unqualified size_t.)

In general, you want to include <X.h>, not <cX>:

* <cX> need only declare/define things in the std namespace and not
  things in the global namespace (even if in practice it often does).
* (Thus <cX> need not declare/define POSIX extensions declared by <X.h>
  at all, in any namespace.)

So unless you want to write std::size_t, std::fopen(), etc., you want
<X.h>.

A weird case is nullptr_t/std::nullptr_t. C++11 decrees that <stddef.h>
define (::)nullptr_t, even though it's a C++ language feature (note that
it need not define std::nullptr_t at all). So in theory one should be
able to just include <stddef.h> and use nullptr_t (in the global
namespace).

Unfortunately, AFAICT, gcc+libstdc++ and clang+libc++ appear to have
different philosophies here. gcc's <stddef.h> just defines nullptr_t, so
libstdc++ doesn't have its own <stddef.h>. clang's <stddef.h> does NOT
define nullptr_t, so libc++ has its own <stddef.h> that defines
nullptr_t (and which then does an #include_next <stddef.h>, picking up
the compiler's <stddef.h>). Thus including <stddef.h> with
clang+libstdc++ does NOT result in nullptr_t being defined (at least on
Linux currently). :-(

So we use std::nullptr_t and include <cstddef>. Note that sometimes we
also do the right thing and ALSO include <stddef.h> (so that we can use
size_t unqualified).

R=jamesr@chromium.org

Committed:
https://chromium.googlesource.com/external/mojo/+/a6a56396e8ce30e46fa2f391476...
==========

[viettrungluu, 2016-01-06 21:25:02]

Committed patchset #1 (id:1) manually as
a6a56396e8ce30e46fa2f391476dcaf586c04344 (presubmit successful).