Rust in the 6.2 kernel [LWN.net]

Rust in the 6.2 kernel

Posted Nov 18, 2022 16:48 UTC (Fri) by ncm (guest, #165)
In reply to: Rust in the 6.2 kernel by khim
Parent article: Rust in the 6.2 kernel

In fact, std::string_view validity does not need to be "kept track of". Passed down a call chain, it remains valid throughout, with no phony "complication". When you need to lie to make your case, it tells us all we need to know about your case. Hype reliant on spurious denigration of other languages adds no value here.

to post comments

Rust in the 6.2 kernel

Posted Nov 18, 2022 17:05 UTC (Fri) by farnz (subscriber, #17727) [Link] (3 responses)

It does need to be kept track of - you need to ensure that the underlying string is not deallocated before the string view is deallocated.

For the very specific case of just passing a string view of a string you own down a call stack, there's no issues, but as soon as the string view relates to a string whose lifespan is not determined purely by the enclosing scope (e.g. because you put the string view in a heap-allocated data structure), you have a lifespan tracking issue to worry about.

Rust in the 6.2 kernel

Posted Nov 18, 2022 18:02 UTC (Fri) by khim (subscriber, #9252) [Link]

If someone claims that use of std::string_view doesn't lead to the problems then you can safely say that it's another crop of the “just don't do any mistakes and then C works fine… oh, and don't upgrade the compiler ever because these evil guys make it break it my programs”, just with C++ theme.

Here is discussion about dangers of std::string_view on the Core Guidelines site, here is article with more arguments and there are more, but they all are, obviously, wrong, because admitting that they are right means years of investment in C++ are in jeopardy.

Just leave these guys alone. It's the same thing as with systemd introduction: there would be lots of complains and there would be holdouts and yet it would happen in the classic planck's principle way:

> An important scientific innovation rarely makes its way by gradually winning over and converting its opponents: it rarely happens that Saul becomes Paul. What does happen is that its opponents gradually die out, and that the growing generation is familiarized with the ideas from the beginning.

Rust in the 6.2 kernel

Posted Dec 12, 2022 21:04 UTC (Mon) by oconnor663 (guest, #119484) [Link] (1 responses)

You (farnz) probably already know this but I think it's worth adding: Not only deallocated, but also reallocated. Calling .push_back() or .append() on the original string also potentially invalidates a string_view.

It could be totally fair to describe these as niche issues that don't affect most callers of string_view. But I don't agree with calling someone a "liar" because you (ncm) think it's niche. Or if these issues are new to you, great! None of us is ever done learning.

Rust in the 6.2 kernel

Posted Dec 13, 2022 11:14 UTC (Tue) by farnz (subscriber, #17727) [Link]

Yes - apologies for being unclear. I think of reallocations as an optimized form of allocate, copy and deallocate, so it's implicit to me that reallocation can invalidate the original string.

At heart, this is the same problem as iterator invalidation. You have a reference to some underlying data, and changes to that underlying data can result in your reference no longer being valid. C++ has no compiler checks for reference validity, and relies on the programmer not getting it wrong; this makes some sense, since any check for reference validity is going to be conservative and thus will need overriding from time to time, but the history of "rely on the programmer not getting it wrong" suggests it's not a great decision.