On 08/23/2010 03:45 PM, Ralf Wildenhues wrote:
* Yavor Doganov wrote on Mon, Aug 23, 2010 at 09:42:54PM CEST:
Eric Blake wrote:
I have to wonder if there are cases where rejecting extra arguments
might not be advisable,
No, the behavior should remain the same (silently ignoring them); any
change smells like a dangerous path to follow. The only difference
would be the warnings (well, errors with -Werror, unfortunately).
The problem with this approach is that we then cannot ever extend a
macro by adding new detected arguments, without also breaking backward
compatibility that way. That means, each feature addition requiring
more arguments would now also require a new macro name, wasting more
good names in the process. :-/
Requiring a minimum number of arguments is problematic - existing code
cannot be compiled with a newer autoconf that requires a larger minimum.
That is, we intentionally document that AC_RUN_IFELSE([arg1]) and
AC_RUN_IFELSE([arg1], [], [], []) are identical, therefore AC_RUN_IFELSE
must not print a warning if $# is less than 4. Or, in m4 terms, we
prefer that choices be made on whether $4 is the empty string, and not
on whether $# == 4; when $4 is a documented argument. The m4 builtin
regexp is an example where regexp([abc],[b]) behaves much differently
than regexp([abc],[b],[]), because it specifically checks $#, but that's
confusing enough that you can see why we don't encourage those semantics
in other autoconf macros.
Meanwhile, I don't see how warning on unexpected arguments is a problem
- code that wants to be portable to both old and new autoconf will only
use as many arguments as the old version supported. On the upgrade
path, if 2.67 supports only ABC(arg1), but 2.68 supports ABC(arg1,
arg2), then calling ABC(arg1, oops) in 2.67 would be a syntax warning,
while in 2.68 it would silently assume you wanted to use the new
argument feature. But it does imply that to get the full benefit of
those portability warnings that you would have to use the oldest version
of autoconf that you plan to be portable to (but also one new enough
that it actually detects and prints warnings in the first place).
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
