Re: segfault in glib-mkenums

[Max Horn <max quendi de>]

At 7:04 Uhr -0700 15.09.2001, <timj localhost > wrote:
> On Sat, 15 Sep 2001, Max Horn wrote:
>
> >  A work around for the crash in glib-mkenums, that I believe should
> >  work on other OSes, too, and will even speed up glib-mkenums a bit is
> >  to change the three occurences of
> >
> >       while (m@/\*([^*]|\*[^/*])*\**$ x) {
> > 	my $new;
> > 	defined ($new = <>) || die "Unmatched comment in $ARGV";
> > 	$_ .= $new;
> >       }
> >
> >  to
> >
> >       while (m@/\*([^*]|\*[^/*])*\**$ x) {
> > 	my $new;
> > 	defined ($new = <>) || die "Unmatched comment in $ARGV";
> > 	next unless ($new =~ m \*/$@);
> > 	$_ .= $new;
> >       }
>
> erk, this isn't really a suitable solution, we have other scripts that
> rely on being able to parse multi line comments.

?!? How does the fact that other scripts may also parse multi line 
comments affect this change? IN this case, you parse the multi line 
comments for only one reason: to throw them away. And this is done 
currently in an extremly wasteful manner, just look at the current 
code and think what it does.


> the correct way to handle this is really updating perl and if that 
> new version still breaks, report a bug against perl to get this 
> fixed.

Let me explain how I see it: the original algorithm in glib-mkenum to 
skip multi line comments in is rather "bad", efficient wise (OTOH it 
is quite clear). It is O(n^2) at least, where n is the number of 
lines. Actually, it is worse if you factor in the pattern matching 
for the rather complicated pattern, but I do not want to argue about 
O notation station or something, I do not really care :).


The reason that perl for me crashed is that to skip a twenty-line 
comment, Perl will recurse to a depth of over 1900 - at this point, 
the stack overflows for me, since on Darwin the default stack size is 
smaller than on other Unices, don't ask me why. So I say, the code 
above will fail to work on any system given a long enough comment. 
Did you try it with a multi-line comment of 1000 lines? ;) Not very 
realistic scenario, sure, but I do not see why it would be bad to add 
in my small change which should improve speed & efficiency, as long 
as you loose nothing.

Granted, this is really a bug in Perl, it shouldn't recurse that deep 
at all, I do not argue that, but still, getting a better 
compiler/machine/OS is not the answer to a "bad" algorithm.

Of course, if there is something wrong in my suggested change on a 
fundamental level (i.e. it doesn't work correctly in some cases), 
that is something different. And of course, one could easy make this 
work even more efficient, I just did a quick & simple hack to make it 
a bit more clever.


Max
--
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max quendi de>
phone: (+49) 6151-494890