Date: Sat, 27 Apr 2019 12:44:00 +0000
R. Martinho Fernandes:
>> In my Overton Window herbceptions are already in the standard and
>> everybody is happy about their performance. Wishful thinking, I know.
>> But we'll see.
>
> I think there is a consideration against defaulting to exceptions where none of this stuff matters because it's a fundamental problem agnostic of any implementation: defaulting to exceptions on things that are likely to deal with external input is defaulting to the creation of denial-of-service vulnerabilities.
How is it denial-of-service if herbceptions are not worse than error
codes in any way?
> well, I am much against leaving the principle of character set
neutrality in c++,
> and I am working to enhance cheracter set features in a pan-character
set way, including some
> stuff for unicode compability, just like much of the unicode works
were to be compatible with posix/c
> and other iso i18n features. Doing unicode only stuff that could
easily be extended to other
> character sets would be against the spirit of c++ imho.
>
> keld
I had this idea but Unicode means code units, code points, scalar
values, grapheme clusters... It's already really hard to implement by
itself, how are we gonna abstract all of this to other character sets?
> Both std::optional and std::span provide 'safe' ways for extracting
> and indexing.
Last time I checked, std::span doesn't have at().
>> In my Overton Window herbceptions are already in the standard and
>> everybody is happy about their performance. Wishful thinking, I know.
>> But we'll see.
>
> I think there is a consideration against defaulting to exceptions where none of this stuff matters because it's a fundamental problem agnostic of any implementation: defaulting to exceptions on things that are likely to deal with external input is defaulting to the creation of denial-of-service vulnerabilities.
How is it denial-of-service if herbceptions are not worse than error
codes in any way?
> well, I am much against leaving the principle of character set
neutrality in c++,
> and I am working to enhance cheracter set features in a pan-character
set way, including some
> stuff for unicode compability, just like much of the unicode works
were to be compatible with posix/c
> and other iso i18n features. Doing unicode only stuff that could
easily be extended to other
> character sets would be against the spirit of c++ imho.
>
> keld
I had this idea but Unicode means code units, code points, scalar
values, grapheme clusters... It's already really hard to implement by
itself, how are we gonna abstract all of this to other character sets?
> Both std::optional and std::span provide 'safe' ways for extracting
> and indexing.
Last time I checked, std::span doesn't have at().
Received on 2019-04-27 14:44:42