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

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 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.