Re: segfault in glib-mkenums

[Owen Taylor <otaylor redhat com>]

Max Horn <max quendi de> writes:

> >You could write something like:
> >
> >       while (m@/\*([^*]|\*[^/*])*\**$ x) {
> >  	my $new;
> >  	defined ($new = <>) || die "Unmatched comment in $ARGV";
> >  	next unless ($new =~ m \*/$@);
> >  	$_ .= $new;
> >       }
> >
> >if ([$_ ends in an open comment]) {
> >     while (1) {
> >         my $new;
> >         defined ($new = <$file>) || die "Unmatched comment in $ARGV";
> >         $_ .= $new;
> >         break if ([$new closes comment] && ![$new ends in an open comment]);
> >     }
> >}
> >
> >But the simpler n^2 algorithm with the makeenums.pl regex's should
> >work fine for comments up to a few hundred lines anyways.
> 
> Sadly, not at all for me :/. I know I know it is not your fault :) It
> is Perl who uses excessivly recursion.

For complicated regular expressions, Perl's use of recursion is not
really inappropriate ... the code in Perl's regular expression
engine is complicated enough without rewriting it to simulate
recursion using a manually mantained stack!

But I believe, and testing I've done here seems to confirm, that the
makeenums.pl regular expressions do _not_ require excessive amounts of
stack space.

(In a simple test,  
  
  $_ =~ /^(?:[^b]|b(?!c))*$/

On a million-character string aaaa......bc requres about 12k
of stack and 40m of heap.)

Are you sure that if you change glib-mkenums to use the makeenums.pl
version of this code, you still run out of heap space?

Regards,
                                        Owen