21.03.2014 12:25, monarch_dodra пишет:
On Thursday, 20 March 2014 at 23:34:02 UTC, Brad Anderson wrote:
I'm a fan of this approach but Timon pointed out when I wrote about it
once that it's rather trivial to get an invalid string through slicing
mid-code point so now I'm not so sure.
It's just as easy to slice mid-codepoint as it is to access a range out
of bounds. In both cases, it's a programming error.
The only excuse I see for throwing an exception for slicing
mid-codepoint, is that
1. programmers are less aware of the issue, so it's more forgiving in a
released program (nobody likes a crash).
2. arguably, it's not the *program* state that's bad. It's the *data*.
Well, in regards to "2", you could argue that program state and data
state is one and the same.
I think I'm still in favor of it because you've obviously got a logic
error if that happens so your program isn't correct anyway (it's not a
matter of bad user input).
If I remember correctly, with a specially written UTF string, it *was*
possible to corrupt program state. I think. I need to double check. I
didn't give it much thought then ("it should virtually never happen"),
but it could be used as deliberate security vulnerability.
Almost nothing to add here. We already have `-noboundscheck` which can
dramatically increase performance, throwing `UTFError` should either use
same mechanics (`-noutfcheck`?) or just be stripped in release.
Personally I'd choose the latter as there are lots of (sometimes very
slow) assertions stripped with `-release` in real programs, which
indicates same critical data corruption.
--
Денис В. Шеломовский
Denis V. Shelomovskij
