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). Sorry if this wasn't clear from my message. > That is, if 2.67 supports macro ABC(arg), then in 2.68 we add > support for ABC(arg1, arg2), there is the question of whether the > person calling ABC(arg1, arg2) will get sane semantics even if they > use 2.67, by silently ignoring arg2. I guess that if the handling of arg2 is important, the package should AC_PREREQ([2.68]), IOW, requiring an implementation of the ABC macro with two arguments. Otherwise, arg2 should be discarded if 2.67 is used as is the current behavior. IMHO. In the first scenario, the warning would even give a hint to bump AC_PREREQ if that is what has to be done. (Typical case: one developer of a project adds a modern autoconf macro, another developer with an older autoconf version discovers this post factum. For new macros not present in the old version, this is a hard failure at autoconf time, but issues like these may remain unnoticed.) > Maybe the thing to do now is add mention of it in TODO, if we don't > come up with a patch right away? Sure, I didn't expect a patch right away... (TBH, I expected an outright reject because ignoring extra arguments may be considered as an Autoconf feature.) Apparently implementing this requires some thought, so it's perfectly fine to document it as a wishlist item, if you decide so.
