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
Manually force the use of __decltype in C++03 with Clang 3.4.
<string> uses `decltype` in a way incompatible with `__typeof__`.
This is problematic when compiling <string> with Clang 3.4 because
even though it provides `__decltype` libc++ still used `__typeof__`
because clang 3.4 doesn't provide __is_identifier which libc++
uses to detect __decltype.
This patch manually detects Clang 3.4 and properly configures
for it.
This allows the graphics/openshadinglanguage port to build with
lang/clang34.
PR: 216054
the end of libc++'s <exception>. This is a workaround for building
Firefox, which generates a rather convoluted maze of standard library
wrapper headers, and this leads to an unfortunate sequence of:
1. wrapper <new> includes libc++ <new>,
2. which includes wrapper <exception>,
3. which includes libc++ <exception>,
4. which includes wrapper <cstdio> (because of -fno-exception),
5. which includes libc++ <new> again,
6. which includes mozalloc.h,
7. which tries to declare operator new with std::bad_alloc,
8. which gives an error because std::bad_alloc is not yet defined.
The <new> inclusion at step 5 does nothing, because the header guard for
<new> was already encountered in step 1. Then when moz_alloc.h tries to
use std::bad_alloc, it is not yet defined, because we are still busy
processing <exception> (where this class is defined) from step 3.
Mozilla has https://bugzilla.mozilla.org/show_bug.cgi?id=1269171 for
this, reported by Jan Beich (jbeich@), but when the fix for it is
applied to Firefox, we get into another, similar problem situation:
1. some header includes wrapper <exception>,
2. which includes libc++ <exception>,
3. which includes wrapper <cstdio> (because of -fno-exceptions),
4. which includes mozalloc.h,
5. which includes wrapper <new>,
6. which includes libc++ <new>,
7. which gives an error defining std::bad_alloc, because std::exception
is not yet defined.
At step 3, we were at the top of libc++'s <exception>, and at that point
std::exception is not yet defined. At step 6, <new> does include
<exception> again, but similar to step 5 in the previous problem case,
the header guard was already encountered, so the whole header is
skipped.
In upstream libc++'s later revisions r279744 and r279763, the reason for
including <cstdio> and <cstdlib> was nullified again, but these commits
are rather large and intrusive. Therefore, move the includes to the
bottom of the file, just before where they are needed. At that point,
std::exception is already fully defined.
Suggested by: Jörg Sonnenberger
