Re: [Boost-users] [review][fixed_string] FixedString review starts today

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.