5 ms·

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

• masklinn 8y ago
  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.
• RReverser 8y ago
  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.
  • htfy96 8y ago
    With static analysis most misuse can also be detected: https://godbolt.org/z/UE-Mb0 https://godbolt.org/z/UE-Mb0, which provides more flexibility than Rust even with NLL
    • roca 8y ago
      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-for-c-lifetimes-10.html 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.
      • htfy96 8y ago
        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.
    • masklinn 8y ago
      > 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.
• roca 8y ago
  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.
  • htfy96 8y ago
    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.
    • roca 8y ago
      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.
• rkangel 8y ago
  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.