[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)