Date: Mon, 02 Feb 2026 08:37:47 -0800
On Monday, 2 February 2026 00:00:04 Pacific Standard Time FPE via Std-Proposals
wrote:
> 4. On Thiago Macieira's security concerns (embedded nulls): Great points –
> these are real risks in untrusted input scenarios. However, going back to
> string_view's original goals: it accelerates code by trusting input
> (avoiding repeated strlen) and consolidating (ptr, len) into one object.
I don't have a problem if one declares that modifying the string underneath
the container and inserting a NUL or removing the one that terminates is
unsupported. That's usually not a problem. Strings are easy to retain
unmodified.
What I have a problem with is trusting basic_string / basic_string_view's
size() and requiring them to not have an embedded NUL. If cstring_view stores
a size value, it must be obtained from strlen() on construction.
wrote:
> 4. On Thiago Macieira's security concerns (embedded nulls): Great points –
> these are real risks in untrusted input scenarios. However, going back to
> string_view's original goals: it accelerates code by trusting input
> (avoiding repeated strlen) and consolidating (ptr, len) into one object.
I don't have a problem if one declares that modifying the string underneath
the container and inserting a NUL or removing the one that terminates is
unsupported. That's usually not a problem. Strings are easy to retain
unmodified.
What I have a problem with is trusting basic_string / basic_string_view's
size() and requiring them to not have an embedded NUL. If cstring_view stores
a size value, it must be obtained from strlen() on construction.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-02-02 16:38:08
