|
From: | Steven G. Johnson |
Subject: | Re: autoconf 2.61: AC_DEFINE variable with parenthesis |
Date: | Wed, 27 Dec 2006 21:50:34 -0500 |
User-agent: | Thunderbird 1.5.0.9 (Macintosh/20061207) |
Paul Eggert wrote:
Paul Eggert wrote:That could well be, but it was never documented and it's not clear to me what the semantics would be. Are arbitrary characters allowed in the macro name? Surely not.No, just things that are valid in cpp #defines.Surely that's too strong as well. Are ellipses "..." allowed? How about C comments, Universal Character Names and UTF-8 in names? Or backslash-newline, which can occur between any two pairs of characters in the above? Or trigraphs lke "??=" and "??/"? These are all valid in cpp #defines, before the ")" that closes the argument list. This stuff can get hairy pretty quickly, which is why we'd need to document exactly what we support, if we want to support it.
If you want to restrict us to the minimal useful subset in order to make autoconf's limited parsing of the AC_DEFINE arguments more convenient, why not say that the characters must be in [A-Za-z0-9_,()], and must form a valid cpp identifier and (optionally) a valid cpp argument list?
(Ellipses are a C99 feature and it would not be a good idea to point users to them in a config.h file.)
What happens if we have AC_DEFINE([NAME(x)], ...) followed by AC_DEFINE([NAME(y)], ...) followed by AC_DEFINE([NAME], ...)?The same thing that happens if you do AC_DEFINE([NAME],[VAL1]) followed by AC_DEFINE([NAME],[VAL2]): the last definition encountered is the one used.That actually worked, despite the change in spelling among [NAME(x)] and [NAME(y)] and [NAME]? That's news to me. But again, whatever the
Yes, it actually works.
rule is, it should be documented. For example, what would happen if there's white space in the name, e.g., [NAME(x, y)] or [ NAME] or [NAME ]?
White space in the name is disallowed according to the current documentation.
Documenting the behavior of multiple AC_DEFINE's would be great, but I don't think it is a valid objection to macros with arguments since multiple-AC_DEFINE behavior isn't documented even in the ordinary (non-argument) case as far as I can tell. But, in any case, it is easy to do: "In the case of multiple AC_DEFINE statements for the same variable name (not including any parenthesized argument list), the last AC_DEFINE encountered is the one used."
Also, ideally I'd like a complete patch: not just the documentation change, but the .m4 change. That is, I'd rather not go back to the old way of doing things, where users could AC_DEFINE any string and then get into real trouble. I'd rather have Autoconf check that the string being defined is in the subset of strings actually supported by Autoconf.
This would be a fine patch, and would not be hard to implement, but it is an orthogonal issue.
I'm not proposing "going back" to an "old way" of doing things. This is not a regression, just documentation of a reasonable and simple feature that autoconf has supported and relied upon internally for 6+ years.
I don't quite understand why you want this documentation to be dependent on completely new features (checking of the AC_DEFINE variable for invalid characters, or documentation of multiple AC_DEFINE statements for the same variable) that apply equally to the old AC_DEFINE stuff.
PS. Another question: is an empty argument list allowed? That wasn't clear to me either.
An empty argument list is allowed only in the C99 standard (although it was widely supported previously). If a user wants to rely on C99 features, that is their call, but I wouldn't recommend it in config.h.
The point is, we should refer to the C standard for the behavior of the argument list, which is defined by the C preprocessor and not by autoconf. Autoconf itself has nothing to do with the interpretation of the argument list, except for some very limited parsing to extract the variable name.
This is not much different from how we treat the *value* of the AC_DEFINE, which again relies on the C standard for its interpretation (our only restriction is that we don't allow newlines).
Steven
[Prev in Thread] | Current Thread | [Next in Thread] |