Keith Marshall schreef, Op 22-2-2013 21:28:
> On 22/02/13 19:03, Erwin Waterlander wrote:
> [strstr() running in linear vs. quadratic time]
>>> What is the outcome of the test, after you make this adjustment?
>> The outcome was yes.
> Which is bad, because...
>>> From the foregoing, it's apparent that MSYS' strstr runs in quadratic
>>> time, so we would expect a result of "no". If your adjustment results
>>> in a fake outcome of "yes", what is the impact for the m4 you've built?
>> I don't know. Would it have impact at all?
> You've already witnessed the impact, in your configure run: potential
> for dramatically slow strstr() searches while running m4.
>> How different would this m4 be from the 1.4.14 we already have?
> I don't know. The test case is extreme, but it's intent is to weed out
> strstr() implementations which run in quadratic time, and to substitute
> a gnulib replacement, which is claimed to run in linear time. I don't
> know if Chuck built m4-1.4.14 with that replacement, or not.
He did not. But in 1.4.14 the test is different and results in a 'no' in
a few seconds.
>>> Is there an autoconf cache variable you can preload, to force the "no"
>>> outcome? If so, it may be prudent to assign it accordingly.
>> I don't know.
> There is. You can find it by looking in config.log, as I did after I
> downloaded m4-1.4.16 from the GNU canonical source, and configured it
> for a native Linux hosted build. You can force configure to skip the
> slow test, and assume the "no" outcome by adding:
> $ ../configure gl_cv_func_strstr_linear=no ...
> followed by any other options you need to specify, to your configure
> command line; (this example assumes you build in a subdirectory of the
> top source directory).
Thanks! configure gl_cv_func_strstr_linear=no results in a (cached) no.
That is better than playing with the value of m. A value of 100000 gave
a 'no' on my desktop, and a 'yes' on my slow laptop. The option doesn't
need to be in the beginning. You can also add it as a last option.