Dangling views: string_view and span

A std::string_view is a pointer and a length. A std::span<T> is a pointer and a count. Neither owns anything. They let a function read a sequence of characters or elements regardless of where it lives (a std::string, a literal, a buffer received from the network) without copying it into a new owner.

For a feed parser this is exactly what you want. A message arrives in a receive buffer; the parser needs to look at the symbol field, compare it, maybe pass it on. With std::string every field would be copied and possibly allocated. With a view, the field is two machine words pointing into the buffer that already holds it.

std::string_view field(std::span<const char> msg, std::size_t off, std::size_t len) {
    return std::string_view(msg.data() + off, len);   // no copy, no allocation
}

Because a view owns nothing, it is valid only while the thing it points into is alive and unchanged. Every bug with views is a case of the referent going away first.

std::string_view venue_of(const Order& o) {
    return o.venue_name();          // venue_name() returns std::string by value
}                                    // the temporary string is destroyed here

The function compiles because std::string converts implicitly to std::string_view. The view points into the temporary's buffer, which is freed at the end of the return statement. For short strings stored in the small buffer, the bytes may still be on the stack and the test may pass; for longer ones they are in freed heap memory. That matches the intermittent failure in the question.

The same thing happens when you store a view:

struct Subscription {
    std::string_view symbol;          // views a string owned by someone else
};
Subscription make_sub(const std::string& s) { return {s}; }
auto sub = make_sub(cfg.get("symbol"));   // get() returns a temporary string: dangling at once

And when the owner changes: a view into a std::string or std::vector that later grows points at the old buffer.

• Use views as function parameters, not return values or members, unless the function returns a view into one of its own parameters and the lifetime is obvious.
• Never create a view of a temporary that outlives the statement.
• Do not store a view in a long-lived object unless that object provably lives shorter than the referent: a parser state that lives within one message's handling is fine; a subscription table that lives all day is not.
• Remember that the referent must not change. A view into a buffer that is reused for the next packet is valid only until the next receive.
• A string_view is not null-terminated. Passing sv.data() to a C function expecting a C string reads past the end.

When something must outlive the source, copy it into an owner. For short fields like symbols, a fixed-size char[8] or a small inline string avoids the heap.

The checklist for the colleague's change: any function that now returns a string_view, any struct member that became a string_view, any call site that passes a temporary string into a function that stores the view, and any view into a buffer that is reused. AddressSanitizer will name the line that freed the memory, which usually makes the fix obvious.