Bug 22673 – .array of a range with length preallocates without checking if the length was lying or not.

``` struct Range { enum size_t length = 100; enum size_t evilRealLength = 50; size_t idx; Type front() { return Type(0); } bool empty() { return idx == evilRealLength; } void popFront() { ++idx; } } ``` This will allocate 100 `Type`s but only 50 will be touched, what happens if those later ones get destructed?

The others will be in the .init state, which should mean the destructor is a no-op on them.

The array allocated is uninitialized. ``` auto result = (() @trusted => uninitializedArray!(Unqual!E[])(length))(); ```

ah i see yeah that's good good. the fix would prolly be to just bit some init over and slice it off then at the end

(In reply to Adam D. Ruppe from comment #3) > ah i see yeah that's good good. > > the fix would prolly be to just bit some init over and slice it off then at > the end I kind of think this should actually error or throw, because I think it's a bit iffy letting these kinds of things fester. There's a wider problem though, if something throws when filling the array up then it will be finalized with (what must be assumed to be, even if it is zero) junk. For that the fix I have is to just write T.init into the memory before passing the exception (this might be a case to catch Throwable) up. Slightly painful to test, I can't quite get the GC to collect before I try and check all the destructions were valid. I might have to put an assert in the destructor (bitch to debug if it ever breaks)

@maxhaton created dlang/phobos pull request #8359 "Fixes issues 22185, 22673" fixing this issue: - Fixes issues 22185, 22673 https://github.com/dlang/phobos/pull/8359

dlang/phobos pull request #8359 "Fixes issues 22185, 22673" was merged into master: - 4eff7e2a312f70cd5a576bcfdd63d8b0022c68b4 by Max Haughton: Fixes issues 22185, 22673 https://github.com/dlang/phobos/pull/8359