[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: _AC_FEATURE_CHECK_LENGTH bug (Was: Re: 4-gary-AC_PROG_GREP.patch)

From: Albert Chin
Subject: Re: _AC_FEATURE_CHECK_LENGTH bug (Was: Re: 4-gary-AC_PROG_GREP.patch)
Date: Wed, 21 Apr 2004 16:45:08 -0500
User-agent: Mutt/1.5.6i

On Wed, Apr 21, 2004 at 01:59:57PM +0100, Gary V. Vaughan wrote:
> |>>The encapsulation within that macro set isn't ideal, but the break 2 is
> |>>an optimisation.
> |
> | The 'break 2' assumes too much. The changelog entry reasons why.
> |
> |        * lib/autoconf/programs.m4 (_AC_FEATURE_CHECK_LENGTH):
> |        Don't assume `break 2' will break out of parent loop as
> |        we don't know how deeply nested we are (AC_PROG_GREP
> |        nests 3-deep).
> All of the users of _AC_PATH_PROG_FEATURE_CHECK are 3 for loops deep.
> 1: _AS_PATH_WALK([$4],
> 2: [for ac_prog in $2; do
> 3:   for ac_exec_ext in '' $ac_executable_extensions; do
> | Am I missing something? Should we not break out early so we can test
> | all values in $2?
> Hmmm... actually I think it should be a 'break 3', since we don't want
> to check the rest of $PATH for another suitable ac_prog.  I think I
> forgot to update it after I put the ac_exec_ext loop in when I was
> factoring the original libtool macros...
> However, if _AC_PATH_PROG_FLAVOR_GNU fails on every tool found, we can't
> break out of the nested for loops just as soon as ac_cv_path_$1 is set
> because the while loop in _AC_FEATURE_CHECK_LENGTH keeps setting it every
> time it finds a better $ac_path_$1.  Breaking out early would find the
> first tool, rather than the best.

We should have a break. That's to dangerous. You're relying on
something from the caller which isn't safe to assume.

albert chin (address@hidden)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]