Do not take address of empty string front

[Jonathan Wakely]

On 23/06/15 22:04 +0200, François Dumont wrote:
>On 22/06/2015 17:10, Jonathan Wakely wrote:
>> On 20/06/15 12:59 +0100, Jonathan Wakely wrote:
>>> On 20/06/15 12:03 +0200, François Dumont wrote:
>>>> Hi
>>>>
>>>>   2 experimental tests are failing in debug mode because
>>>> __do_str_codecvt is sometimes taking address of string front() and
>>>> back() even if empty. It wasn't use so not a big issue but it still
>>>> seems better to avoid. I propose to rather use string begin() to get
>>>> buffer address.
>>>
>>> But derefencing begin() is still undefined for an empty string.
>>> Shouldn't that fail for debug mode too? Why change one form of
>>> undefined behaviour that we diagnose to another form that we don't
>>> diagnose?
>>>
>>> It would be better if that function didn't do any work when the input
>>> range is empty:
>>>
>>> --- a/libstdc++-v3/include/bits/locale_conv.h
>>> +++ b/libstdc++-v3/include/bits/locale_conv.h
>>> @@ -58,6 +58,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>>                    _OutStr& __outstr, const _Codecvt& __cvt, _State&
>>> __state,
>>>                    size_t& __count, _Fn __fn)
>>>    {
>>> +      if (__first == __last)
>>> +       {
>>> +         __outstr.clear();
>>> +         return true;
>>> +       }
>>> +
>
>Shouldn't it also set __count to 0 to make clear that nothing has been
>converted.

Yes, thanks. Fixed like so.

Tested powerpc64le-linux, in debug and normal modes, committed to trunk.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 565 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20150625/0ea174c9/attachment.bin>