Pelle Månsson pelle.mansson at
Thu Nov 11 14:45:39 PST 2010

On 11/11/2010 10:15 PM, spir wrote:

> Well, since the pattern is OK _after_ call to Tuple's constructor (which does nothing more than recording its sub-patterns, see below) and only gets wrong when qutting this(), I fail to see how Tuple could be cause of anything. Also, the corruption is visible _before_ calling match() (which here delegates to Tuple's check()).
> I understand your note about returning an object actually allocated on the stack -- but here there are only implicitely referenced objects (class instances). This would mean that D creates the 2 sub-patterns on the stack? But why those objects, precisely? (Also note that they are of different classes: one is here a "String", the other a "ZeroOrMore"). They are stored in an array.
> What's troubling is that the array elements, meaning the supposed subpattern addresses, have changed. Maybe the patterns themselves are still ok, but the array data only are corrupted?
> Oh, I may try to cast to String the memory area pointed inside this()....... Does not seem to work: I recorded the pointer read in this() (as String*) into a global; then in the test func:
>      writeln("p: ",p);       	// ok, same address as in this()
>      writeln(cast(String)(*p));	// segfault!
> Anyway, just in case my reasoning is wrong, here is the whole Tuple class:
> ====================================================
> class Tuple : Pattern {
>      /**  pattern type for tuple of given patterns */
>      static string typename = "Tuple";
>      Pattern[] patterns;
>      this (Pattern[] patterns...) {
>          this.patterns = patterns;

You need to dup that. Arguments are passed on the stack.

More information about the Digitalmars-d-learn mailing list