From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-12-03 15:43:14
On Mon, Dec 2, 2019 at 5:42 PM Gavin Lambert via Boost <
> 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
> >>> 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
> > remains the same, however. I know statically how much room I have in
> > 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.
All true, but I'm unclear why you're pointing this out. I never suggested
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk