Hacker News Reader

Comment by dgellow | Hacker News Reader

> While (for a good reason) this might sound scary in unsafe languages like C / C++, in Rust all strings are bounds checked by default.

What’s the good reason, if I may ask?

View on HN

I'm guessing because an off-by-one or an extra skip might mean you miss the end of the string and go off into la-la land feeding whatever garbage happens to be in memory to your parser? That would mostly be a C issue (as it has no string abstraction at all).

Precisely this, thanks. And it's not like this has happened to us before, right? :)

Context: https://blog.cloudflare.com/incident-report-on-memory-leak-c...

They can use str.at() in C++ to ensure boundary safety

Hence my noting this is more of a C issue, or more specifically more of an issue with C strings, such as any string you don't have ownership of because it comes from a buffer you were jut handed, because I don't quite know how much of a thing string_view is yet.

And of course there's a very fine line in C++ between "ensure boundary safety" (s.at) and "here comes a buffer over-read" (s[]).

In Rust by contrast, the latter is spelt `unsafe { s.get_unchecked() }` so it's a bit harder to miss / fat finger it in.

Boundary safety is only one of many possible issues. For example, Rust makes it easier to work with arbitrary slices (not copied substrings) while statically verifying ownership of the original string.

With static analysis most misuse can also be detected: https://godbolt.org/z/UE-Mb0, which provides more flexibility than Rust even with NLL

I'm not aware of any evidence that C++ Lifetimes will detect "most misuse". It will detect some common lifetime errors. It will certainly fail to detect other common lifetime errors. https://robert.ocallahan.org/2018/09/more-realistic-goals-fo...

Since it fails to detect common lifetime errors, it's not surprising it's more "flexible" than Rust NLL, which prevents all lifetime errors.

The true negative in the post has been fixed. Rust also doesn't prevent all dangling references as long as you depend on some unsafe third-party library/external library/libc calls and use them in an improper way.

> which provides more flexibility than Rust even with NLL

Not detecting issues being more flexible than detecting issues surprises no one. Raw pointers are also "more flexible" than smart pointers let alone borrow-checked references.

Unfortunately at() is not idiomatic C++. If you don't have tools to automatically prevent idiomatic unsafe C++ features ([], pointer arithmetic) from being used, developers are surely going to use them.

We use -D_GLIBCXX_DEBUG which automatically checks subscript access to vectors. Raw pointer usages are restricted to local (within a class/function) non-owning cases.

Fine, but neither of those practices are idiomatic C++. The first is also going to really hurt performance since C++ libraries and tools don't optimize for that case.

The top level program can use str.at(), but does every string function everywhere in all your libraries use str.at()?

This is likely to be a particular problem for strings (as supposed to any other structure), due to the long and complicated history of strings in C and C++. There are likely to be many string functions across the codebase, and null termination in some contexts confuses the issue even more.

I see, thank you for the answer.

Reply on news.ycombinator.com