[libcxx-commits] [PATCH] D131425: [libc++] Remove workarounds for systems that used to require __need_XXX macros

James Y Knight via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue Nov 22 13:50:32 PST 2022


jyknight added a comment.

FWIW, the purpose of all the gunk in stddef.h was to allow a libc implementation to retrieve only a particular //subset// of the names from the compiler-provided stddef.h. E.g. stdlib.h is specified to define size_t and wchar_t, but not ptrdiff_t/etc. Whether that level of pedantic namespace cleanliness is ever actually useful seems...questionable. But, someone felt it was a useful goal at some point, at least.

For C++ code, though, I really doubt it can matter -- we're already pretty-much hosed in terms of namespace pollution by unconditionally setting __GNU_SOURCE. What's a few more extraneous names after all that?

(Of course, making a standard header which supports magic defines to modify its behavior was a pretty yucky way to have implemented this libc/compiler cooperation. And we have a better way for the compiler to communicate these types to libc, anyways -- the built-in `__PTRDIFF_TYPE__`, `__SIZE_TYPE__`, `__WINT_TYPE__`, etc.)

But -- for this simplification to work, I think at minimum it needs to undef each of these macros before the include_next -- in order to ensure that it's NOT getting any header subsets from the include_next.

Otherwise, you break code like

  #define __need_ptrdiff_t 1
  // intended to define only ptrdiff_t.
  #include <stddef.h>
  ...
  // Now include full stddef.h...but this hits libc++ stddef.h's header guard, and becomes a no-op
  #include <stddef.h>

I think the minimal implementation is to undef each of the "need" macros before the `#include_next <stddef.h>`. And the same for each of the other affected headers.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D131425/new/

https://reviews.llvm.org/D131425



More information about the libcxx-commits mailing list