From: Gavin Lambert (boost_at_[hidden])
Date: 2019-12-02 23:42:04
On 3/12/2019 07:02, Zach Laine wrote:
> On Mon, Dec 2, 2019 at 11:48 AM Peter Dimov wrote:
>
>> Zach Laine wrote:
>>
>>> I don't find it natural that a type whose size is statically known and a
>>> type whose size is not statically known have the same relationship to
>>> user code (preconditions, use of UB vs. exceptions, etc.).
>>
>> But the size of the proposed fixed_string isn't statically known. Its
>> capacity is.
>
> Right, thanks. I wrote "size" when I meant "capacity". I think the point
> remains the same, however. I know statically how much room I have in which
> to operate, as opposed to having a runtime-variable amount of room.
But given fixed_string<N> and fixed_string<M>, there is no way to
determine at compile time whether direct concatenation is safe or will
overflow, even presuming you are appending to the larger of the two.
The only way to guarantee at compile time that a concatenation is not at
risk of overflow is to first copy to a fixed_string<N+M> and then
append, which (in the primary intended use case of allocating a large
buffer up-front and not using most of it) is a massive waste of both
performance and memory.
Thus (assuming we're appending into one of the existing buffers
instead), *someone* needs to do a range check at runtime, and forgetting
it is a serious security vulnerability. If we lived in a world where
sanitisers were readily available, reliable, and automatically run on
all code, then maybe you can argue that this is the user's
responsibility and UB is "safe". We still do not yet live in that world.