PR 58148 patch

[François Dumont]

On 08/26/2013 10:40 PM, Paolo Carlini wrote:
> On 08/26/2013 09:44 PM, François Dumont wrote:
>> Hi
>>
>>     The problem exposed in PR 58148 is quite trivial, 
>> std::common_type cannot find a result when instantiated with char* 
>> and const wchar_t*. The attached patch will fix this problem by 
>> dealing with a std::common_type resolution failure even if the 
>> drawback is that following call won't be detected as an invalid one 
>> anymore:
>>
>>   std::vector<int> v;
>>   ....
>>   v.insert(v.begin(), reinterpret_cast<char*>(v.data() + 1), 
>> reinterpret_cast<char*>(v.data() + 5)); // Expected failure
> For the time being I think we should simply live with this. To be 
> honest, I think that at this level even the very idea of using 
> common_type (and relying on the very recent sfinae-friendly feature) 
> is a bit too much, I would just return true if the type of 
> addressof(*__other) != container::pointer (modulo const). Thus have a 
> __foreign_iterator_aux4 taking two container::const_pointer and a fall 
> back always returning true.
>
> Paolo.
>
     As you seem to be more concern by the usage of experimental 
std::common_type than by the usage of const volatile void*I would like 
to propose the attached patch. No more usage of common_type but still 
able to detect weird issues.

Tested under Linux x86_64 debug mode.

2013-08-27  François Dumont  <fdumont@gcc.gnu.org>

     PR libstdc++/58148
     * include/bits/functions.h: Use const volatile void* as common
     type rather than result of std::common_type. Add a fallback method
     if conversion to const volatile void* is not possible.
     * testsuite/23_containers/vector/modifiers/insert/58148.cc: New.

Ok to commit ?

François


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 58148.patch
Type: text/x-patch
Size: 3634 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20130827/1d3d889a/attachment.bin>