bug-autoconf
[Top][All Lists]
Advanced

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

Re: autoconf 2.61: AC_DEFINE variable with parenthesis


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





reply via email to

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