[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