[libc++] Harden usage of static_assert against C++03
In C++03, we emulate static_assert with a macro, and we must
parenthesize multiple arguments.
llvm-svn: 373328
This is a follow-up to r354460, which causes errors for pre-C++11
programs using <cmath>, similar to:
/usr/include/c++/v1/cmath:622:68: error: too many arguments provided to
function-like macro invocation
Reported by: antoine
MFC after: immediately (because of ports breakage)
[libc++] Add `__truncating_cast` for safely casting float types to
integers
This is needed anytime we need to clamp an arbitrary floating point
value to an integer type.
Thanks to Eric Fiselier for the patch.
Differential Revision: https://reviews.llvm.org/D66836
llvm-svn: 370891
Merge commit b92deded8 from llvm git (by Louis Dionne):
[libc++] Move __clamp_to_integral to <cmath>, and harden against
min()/max() macros
llvm-svn: 370900
Merge commit 0ec6a4882 from llvm git (by Louis Dionne):
[libc++] Fix potential OOB in poisson_distribution
See details in the original Chromium bug report:
https://bugs.chromium.org/p/chromium/issues/detail?id=994957
Together, these fix a security issue in libc++'s implementation of
std::poisson_distribution, which can be exploited to read data which is
out of bounds.
Note there are no programs in the FreeBSD base system that use
std::poisson_distribution, so this is only a possible issue for ports
and external programs which have been built against libc++. Therefore,
I am bumping __FreeBSD_version for the benefit of our port maintainers.
Requested by: emaste
Security: potential OOB read
MFC after: 3 days
GCC compilers set __FreeBSD__ statically to a build-time determined
targeted version (which in ports always matches the build host's
version). This means that when building any version (12 or 13, etc.)
of riscv or some other architecture via GCC on a 12.x host,
__FreeBSD__ will always be set to 12. As a result, __FreeBSD__ cannot
be used to reliably detect the target FreeBSD version being built.
Instead, __FreeBSD_version from either <sys/param.h> (in the kernel)
or <osreldate.h> (in userland) should be used.
This changes the gets() test in libc++ to use __FreeBSD_version from
<osreldate.h>.
Reported by: jenkins (riscv64 and amd64-gcc)
Reviewed by: dim, imp
Differential Revision: https://reviews.freebsd.org/D22034
Instead, pull in r371324 from upstream libc++ trunk (by me):
Remove ::gets for FreeBSD 13 and later
Summary:
In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed
gets() from FreeBSD 13's libc, and our copies of libc++ and
libstdc++. In that change, the declarations were simply deleted, but
I would like to propose this conditional test instead.
Reviewers: EricWF, mclow.lists, emaste
Reviewed By: mclow.lists
Subscribers: krytarowski, christof, ldionne, emaste, libcxx-commits
Differential Revision: https://reviews.llvm.org/D67316
This makes these changes more MFCable.
gets is unsafe and shouldn't be used (for many years now). Leave it in
the existing symbol version so anything that previously linked aginst it
still runs, but do not allow new software to link against it.
(The compatability/legacy implementation must not be static so that
the symbol and in particular the compat sym gets@FBSD_1.0 make it
into libc.)
PR: 222796 (exp-run)
Reported by: Paul Vixie
Reviewed by: allanjude, cy, eadler, gnn, jhb, kib, ngie (some earlier)
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D12298
Rework recursive_timed_mutex so that it uses __thread_id instead of
using the lower-level __libcpp_thread_id. This is prep for fixing
PR42918. Reviewed as https://reviews.llvm.org/D65895
Pull in r368916 from upstream libc++ trunk (by Marshall Clow):
Fix thread comparison by making sure we never pass our special 'not a
thread' value to the underlying implementation. Fixes PR#42918.
This should fix std:🧵🆔:operator==() attempting to call
pthread_equal(3) with zero values.
Reported by: andrew@tao11.riddles.org.uk
PR: 239038, 239550
MFC after: 3 days
Fix the build with gcc when `-Wredundant-decls` is passed
Summary:
gcc warns that `__throw_runtime_error` is declared both in
`<__locale>` and `<stdexcept>`, if `-Wredundant-decls` is passed on
the command line; this is the case with FreeBSD when ${WARNS} == 6.
Since `<__locale>` gets its first declaration via a transitive
include of `<stdexcept>`, and the second declaration is after the
first invocation of `__throw_runtime_error`, delete that second
declaration.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
Reviewers: kristina, MaskRay, EricWF, ldionne, ngie
Reviewed By: EricWF
Subscribers: krytarowski, brooks, emaste, dim, christof, jdoerfert, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D58425
Submitted by: ngie
MFC after: 3 days
Revert "Teach __libcpp_is_floating_point that __fp16 and _Float16 are
floating-point types."
This reverts commits r333103 and r333108. _Float16 and __fp16 are C11
extensions and compilers other than Clang don't define these for C++.
Differential Revision: https://reviews.llvm.org/D53670
This prevents "_Float16 is not supported on this target" errors in
libc++'s type_traits header, in some cases.
Reported by: Charlie Li
MFC after: 3 days
An integrity check such as a check-hash or a cross-correlation failed.
The integrity error falls between EINVAL that identifies errors in
parameters to a system call and EIO that identifies errors with the
underlying storage media. EINTEGRITY is typically raised by intermediate
kernel layers such as a filesystem or an in-kernel GEOM subsystem when
they detect inconsistencies. Uses include allowing the mount(8) command
to return a different exit value to automate the running of fsck(8)
during a system boot.
These changes make no use of the new error, they just add it. Later
commits will be made for the use of the new error number and it will
be added to additional manual pages as appropriate.
Reviewed by: gnn, dim, brueffer, imp
Discussed with: kib, cem, emaste, ed, jilles
Differential Revision: https://reviews.freebsd.org/D18765
higher mode, in <https://reviews.llvm.org/rL338419>. Since we do not
yet have this C11 function, comment out the line for now, as a
workaround for a number of failing ports. Discussion with upstream is
ongoing about an acceptable permanent fix.
PR: 230400
Reported by: jbeich
Add pre-C++11 is_constructible wrappers for 3 arguments
Summary:
After rL319736 for D28253 (which fixes PR28929), gcc cannot compile
<memory> anymore in pre-C+11 modes, complaining:
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::make_shared(_A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4365:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4365:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::allocate_shared(const _Alloc&, _A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4444:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4444:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
This is also reported in https://bugs.freebsd.org/224946 (FreeBSD is
apparently one of the very few projects that regularly builds
programs against libc++ with gcc).
The reason is that the static assertions are invoking
is_constructible with three arguments, while gcc does not have the
built-in is_constructible feature, and the pre-C++11 is_constructible
wrappers in <type_traits> only provide up to two arguments.
I have added additional wrappers for three arguments, modified the
is_constructible entry point to take three arguments instead, and
added a simple test to is_constructible.pass.cpp.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: krytarowski, cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D41805
This should allow gcc to compile the libc++ 6.0.0 <memory> header
without problems, in pre-C++11 mode.
Reported by: jbeich
PR: 224946
