Jeffrey Walton wrote:
> Then you have Apple's version of Clang. They are probably C++03 for
> compatibility reasons for Xcode developers. So even if LLVM moved to
> C++11, Apple's Clang may stay at C++03.
Ah, that explains the nullptr issue with this compiler, and also why
we have to test __apple_
Paul Eggert wrote:
> Let's treat C++ overloading like we already treat C _Generic, that is,
> as a documented limitation of the substitute nullptr macro. This should
> be good enough for Gnulib itself. I installed the attached to document
> that, and to work around the Apple clang 14 incompatibi
On 2/9/23 11:31, Bruno Haible wrote:
* If we '#define nullptr __null' again after including the header files,
it will be usable with varargs, but will
- violate the requirement that nullptr is an instance of nullptr_t,
- and thus open up problems with overloading again.
I do
Hi,
Bruno Haible writes:
> On macOS 12.5 (machine: gcc104.fsffrance.org), the test-nullptr-c++.cc fails
> to compile:
>
> -
> Making check in .
> c++ -DHAVE_CONFIG_H -I. -I../../gltests -I.. -DGNULIB_STRICT_CHECKING=1
On Thu, Feb 9, 2023 at 2:31 PM Bruno Haible wrote:
>
> On macOS 12.5 (machine: gcc104.fsffrance.org), the test-nullptr-c++.cc fails
> to compile:
One of the sharp edges you may be encountering is, LLVM was shipping a
C++03 compiler by default. You had to do something special to use
C++11 (-std=c+
On macOS 12.5 (machine: gcc104.fsffrance.org), the test-nullptr-c++.cc fails
to compile:
-
Making check in .
c++ -DHAVE_CONFIG_H -I. -I../../gltests -I.. -DGNULIB_STRICT_CHECKING=1
-DIN_GNULIB_TESTS=1 -I. -I../../gltest
