This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch] libstdc++/65352 fix ubsan errors in std::array<T, 0>
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 28 May 2015 15:14:28 +0100
- Subject: Re: [patch] libstdc++/65352 fix ubsan errors in std::array<T, 0>
- Authentication-results: sourceware.org; auth=none
- References: <20150528115330 dot GL2985 at redhat dot com> <alpine dot DEB dot 2 dot 11 dot 1505281522500 dot 11312 at stedding dot saclay dot inria dot fr> <20150528133817 dot GP2985 at redhat dot com> <20150528134042 dot GQ2985 at redhat dot com> <alpine dot DEB dot 2 dot 11 dot 1505281545200 dot 11312 at stedding dot saclay dot inria dot fr>
On 28/05/15 15:52 +0200, Marc Glisse wrote:
On Thu, 28 May 2015, Jonathan Wakely wrote:
Would there be a danger of an object compiled with gcc-5.1 that calls
array<T, 0>::data() finding the _S_ref from an object compiled with
gcc-5.2 and hitting the __builtin_unreachable in vali code?
At -O0, maybe. To be safe you would need to give this _S_ref an
arbitrary abi_tag.
Or just rename it.
You could also replace all uses of _S_ref with *_S_ptr.
I considered this, but I thought that changing _S_ref(_M_elems, n) to
_S_ptr(_M_elems)[n] would fail to give an error for out-of-range
accesses in constant expressions e.g.
constexpr std::array<int, 1> a{};
constexpr int i = a[1];
But it still seems to give an error, so maybe getting rid of _S_ref
entirely is the way to go.