Shouldn't SList in std.container hold an owner pointer to verify a range belongs to the list?
monarch_dodra
monarchdodra at gmail.com
Tue Dec 17 06:52:35 PST 2013
On Monday, 16 December 2013 at 21:57:52 UTC, Andrej Mitrovic
wrote:
> Here's some improper code that is not checked properly by SList
> (meaning no assertions, not even in debug mode):
>
> -----
> import std.stdio;
> import std.container;
>
> void main()
> {
> auto s1 = SList!string(["a", "b", "d"]);
> auto s2 = SList!string(["a", "b", "d"]);
>
> // note the s1[] instead of s2[]!
> s2.insertAfter(std.range.take(s1[], 2), "c");
>
> writeln(s1[]); // updated s1, not s2!
> writeln(s2[]); // s2 stays the same.
> }
> -----
>
> Note the docs of insertAfter:
>
> Inserts $(D stuff) after range $(D r), which must be a range
> previously extracted from this container.
>
> Well clearly we have a range extracted from one list being used
> to add
> items to a different list, but SList makes no checks at all to
> verify
> the range belongs to it. I had a look at DCollections[1], and it
> stores an "owner" pointer (or reference) in the range type when
> its
> extracted from a linked-list, so it can do these types of sanity
> checks.
>
> So shouldn't we add this to SList? We'd have to add an owner
> field to
> its internal "Range" struct.
>
> [1] : https://github.com/schveiguy/dcollections
Didn't I reply to this already?
Anyways... what I said is that we can add the test in
non-release, but I see it as assertive code, so it can be removed
in release.
I'd be more afraid of DList's current semantics: Neither value
nor ref. I've been trying to fix it for more than a year now:
https://github.com/D-Programming-Language/phobos/pull/953
More information about the Digitalmars-d-learn
mailing list