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

On Mon, Dec 2, 2019 at 5:42 PM Gavin Lambert via Boost < boost@lists.boost.org> 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

On 3/12/2019 07:02, Zach Laine wrote: 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.

All true, but I'm unclear why you're pointing this out. I never suggested otherwise.

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.

I get the point you're making. What I do not get is why you *only* apply it to op+. That is, if memory is so essential for op+, then why is it not also essential for op[] . This is not a troll. I really do want to know what the difference is as you see it. Zach