funny bug with input range interface and toString
Hello,
I have a strange bug with an input range interface. Initially, I had a (rather
big) struct called Text with loads of working unittests. When adding a range
interface, noting worked anymore, any test ran into an infinite loop (the
terminal writes pages of '[') ending with segfault.
After shrinking the bug's scope,I finally found it happens on simple
writeln(text). Which is rather weird, because my toString does not iterate on
texts properly speaking (instead on a private array field). Thus, i had the
idea to force using toString by explicitely calling it and the bug vanished ;-)
So, here is the situation:
unittest {
auto text = Text(bäcon);
writeln(text); // -- infinite loop segfault
writeln(text.toString()); // OK
}
Indeed, if I remove the range interface, the bug vanishes as well.
You can find a stripped version of the module, with only the minmum to expose
the bug, at
https://bitbucket.org/denispir/denispir-d/changeset/39200b499fb9#chg-textbug.d.
Note that the range interface itself works fine.
So, it seems that, in my case for any reason, introducing an input range lets D
shortcut toString (and try to use what instead?). Look like a bug?
denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: funny bug with input range interface and toString
On Mon, 13 Dec 2010 11:24:48 +0300, spir denis.s...@gmail.com wrote:
I have a strange bug with an input range interface. Initially, I had a
(rather big) struct called Text with loads of working unittests. When
adding a range interface, noting worked anymore, any test ran into an
infinite loop (the terminal writes pages of '[') ending with segfault.
@property Text front () {
return Text(this.stacks[this.rangeIndex]);
}
Um. There is recursion. front() of Text returns Text. formatValue iterates
through Range, trying to format every element of it... but goes nowhere
because Range.front never yields anything but itself typewise.
After shrinking the bug's scope,I finally found it happens on simple
writeln(text).
Not so simple, with all underlying mess of templates :-D I suppose it's a
bug that instantiation of formatValue for Range types there always tries
to iterate manually, ignoring existing toString.
void formatValue(Writer, T, Char)(Writer w, T val,
ref FormatSpec!Char f)
if ( ( is(T == struct) || is(T == union) ) !isInputRange!T)
As you can see it even explicitly mention that default formatting for
struct (which can use toString) not to be used for Ranges. I think it's
wrong.
https://bitbucket.org/denispir/denispir-d/changeset/39200b499fb9#chg-textbug.d.
Note that the range interface itself works fine.
btw, I wonder, how do you build it? I ended up with very long command line
for dmd, as there was no makefile and jake/rdmd failed to produce anything
ether.
So, it seems that, in my case for any reason, introducing an input range
lets D shortcut toString (and try to use what instead?). Look like a bug?
Yup! Still, stack overflow is due to unconventional Range interface.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: funny bug with input range interface and toString
On Mon, 13 Dec 2010 17:37:19 +0300
Nick Voronin elfy...@gmail.com wrote:
On Mon, 13 Dec 2010 11:24:48 +0300, spir denis.s...@gmail.com wrote:
I have a strange bug with an input range interface. Initially, I had a
(rather big) struct called Text with loads of working unittests. When
adding a range interface, noting worked anymore, any test ran into an
infinite loop (the terminal writes pages of '[') ending with segfault.
@property Text front () {
return Text(this.stacks[this.rangeIndex]);
}
Um. There is recursion. front() of Text returns Text. formatValue iterates
through Range, trying to format every element of it... but goes nowhere
because Range.front never yields anything but itself typewise.
Yes, but returning an element of the same type is the write thing here. (Like
in dynamic languages where s[i] returns a singleton s).
After shrinking the bug's scope,I finally found it happens on simple
writeln(text).
Not so simple, with all underlying mess of templates :-D I suppose it's a
bug that instantiation of formatValue for Range types there always tries
to iterate manually, ignoring existing toString.
void formatValue(Writer, T, Char)(Writer w, T val,
ref FormatSpec!Char f)
if ( ( is(T == struct) || is(T == union) ) !isInputRange!T)
As you can see it even explicitly mention that default formatting for
struct (which can use toString) not to be used for Ranges. I think it's
wrong.
You are right. (With some offline help) finally ended up following the same
reasoning and got to the same conclusion. This is clearly a bug (actualy 2 or
3). I'll post about it on D's main mailing list.
https://bitbucket.org/denispir/denispir-d/changeset/39200b499fb9#chg-textbug.d.
Note that the range interface itself works fine.
btw, I wonder, how do you build it? I ended up with very long command line
for dmd, as there was no makefile and jake/rdmd failed to produce anything
ether.
I use rdmd for quick testing (because it links automagically).
compile: dmd -w -c filename.d
build: rdmd -w -offilename -debug -unittest --build-only filename.d
So, it seems that, in my case for any reason, introducing an input range
lets D shortcut toString (and try to use what instead?). Look like a bug?
Yup! Still, stack overflow is due to unconventional Range interface.
Yes. But the formatValue template selection criteria _must_ check this!
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: funny bug with input range interface and toString
On Mon, 13 Dec 2010 21:43:33 +0300, spir denis.s...@gmail.com wrote: I use rdmd for quick testing (because it links automagically). compile: dmd -w -c filename.d build: rdmd -w -offilename -debug -unittest --build-only filename.d Thanks. I missed -of option. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
