Re:Implications of Rewriting a Browser Component in Rust
by TheAsprngHacker on Thursday February 28, 2019 @03:42PM
(#19274973)
Huh. According to https://en.cppreference.com/w/cpp/container/vector/operator_..., “no bounds checking is performed.” I find cppreference.com generally trustworthy, but maybe it’s wrong here? Or, maybe “no bounds checking” actually means “no guaranteed bounds checking?”
[ Parent
| on HN ]
Re:Implications of Rewriting a Browser Component in Rust
by pjmlp on Thursday February 28, 2019 @05:21PM
(#19275859)
It means “no guaranteed bounds checking”, the standard only requires at() to throw if out of bounds (§ 26.2.4.1, note 15), but leaves unspecified how operator[]() should behave in invalid accesses, only that it isn't allowed to throw.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n471...
Here is the Visual C++ documentation for bounds checking in debug builds.
https://docs.microsoft.com/en-us/cpp/standard-library/checke...
Re:Implications of Rewriting a Browser Component in Rust
by int_19h on Thursday February 28, 2019 @08:32PM
(#19277229)
You need to look at the text of the Standard itself when it comes to this level of language lawyering. The short answer is that operator[] has undefined behavior if the index is out of range. Performing a check and terminating the program with some kind of runtime error is a legal subset of "undefined behavior", and so it's commonly done in debug builds, but you cannot rely on it in any sense.