This is why I call string_view a "parameter-only type": it's fine to take as a parameter, but not fine to return or to store as a variable. (For sane definitions of "fine" and "not fine," of course. The blog post demonstrates one way it can go "not fine.")
std::string_view username = Sanitize("foobarbazboo");
^- temporary std::string created here
std::string_view Sanitize(const std::string& input) { ... }
^ ^- reference to that temporary string
+- returns a view to a temporary string
std::string_view username = // possibly data freed and dangling string
But if Sanitize has a return type of string_view, then returning the temporary variable should make a copy of it (or move it), right? And the string "foobarbazboo" is static so that's not being freed either.
And the while loop shouldn't even run at all since front() never equals ' '.
But it's not actually taken as a reference (with &) anywhere I see... and even if it's just internally referencing the (static) string, there shouldn't be any issue with that memory either right?
https://quuxplusone.github.io/blog/2018/03/27/string-view-is...
The real fix is don't pass in a temporary to the sanitize function.
I've got a nice `==31604==ERROR: AddressSanitizer: stack-use-after-scope on address`
12 != 8
I don't get it...
> As you can guess, this is an example of undefined behavior causing unintuitive results.
No I couldn't... and what undefined behavior where? They don't explain anything.
And the bug comes from the temporary string object created when he passes in the string to Sanitize.
Sanitize("foobarbaz") -> creates temporary string -> string_view from temporary string -> returns string_view of temporary string
temporary string destructed
operations on returned string_view -> oops, use after free.q
And the while loop shouldn't even run at all since front() never equals ' '.