array.reverse segfaults

[Moritz Warning]

On Wed, 22 Oct 2008 17:46:26 +0400, Denis Koroskin wrote:

> On Wed, 22 Oct 2008 15:21:03 +0400, Moritz Warning
> <moritzwarning at web.de> wrote:
> 
>> On Wed, 22 Oct 2008 13:10:20 +0200, Tomas Lindquist Olsen wrote:
>>
>>> Tomas Lindquist Olsen wrote:
>>>> Moritz Warning wrote:
>>>>> Hi,
>>>>>
>>>>> This piece of code segfaults on Debian Linux (with dmd 1.035): Can
>>>>> someone tell me why?
>>>>>
>>>>> char[] get(char[] str)
>>>>> {
>>>>>     return new char[](4);
>>>>> }
>>>>>
>>>>> void main(char[][] args)
>>>>> {
>>>>>     char[] str =  get("abc");
>>>>>    char[] reversed = str.reverse; // <-- access violation
>>>>> }
>>>>
>>>> Simpler version:
>>>>
>>>> void main()
>>>> {
>>>>     char[4] str;
>>>>     str.reverse;
>>>> }
>>>>
>>>> Crashes in _adReverseChar when trying to memmove (3 - 255) bytes ;)
>>>>
>>>> My best guess is that is just doesn't handle char.init values
>>>> properly!
>>>
>>> When it tries to get the lower stride, it gets 0xFF from the table,
>>> but it doesn't check if this value is usable.
>>>
>>> Probably just ignoring these invalid bytes would make it work. But I
>>> think the real question is, what should _adReverseChar really do on
>>> invalid UTF-8 input?
>>
>> I think it should do the same as on an invalid pointer: result in
>> undefined behavior (=> segfault).
> 
> It should not pass the assert(isValidUtf8String(str)) prior to in-place
> reverse, thus throwing an exception in debug mode. Release behaviour is
> a subject to debat, but I think it should be more robust. Given wrong
> input it may produce whatever wrong output, but segfault? That's too
> bold.

I was only referring to release builds.
Imho, If additional robustness doesn't result in a speed hit,
then throwing an exception would be better.