bug-gnulib
[Top][All Lists]
Advanced

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

Re: avoiding obsolete macros like AC_TRY_RUN


From: Paolo Bonzini
Subject: Re: avoiding obsolete macros like AC_TRY_RUN
Date: Thu, 03 Sep 2009 09:48:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3

    Drawbacks of AC_*_IFELSE:
      - Unmnemonic naming of the macros. Macros and procedure names should 
follow
        the convention of "verb" or "verb_noun", so that they can better be
        remembered by people who are familiar with English grammar.

Well, the common name was already taken. :-(

      - Danger if a single level of quoting is used instead of double quoting:
        Array declarations and array accesses get silently botched in that
        case. The autoconf manual uses double-quoting in the examples of
        AC_LANG_SOURCE and AC_LANG_PROGRAM, which is good. But some advocates 
like
        you propagate single-quoting.

That's not why Ralf used single quoting. He did so to achieve consistency, where only the ultimate caller uses double quoting of arguments. You're welcome to write

  AC_LANG_SOURCE([[
    #include <stdio.h>
    extern char foo[];
    int main ()
    {
      ]$1[
    }]])

where most of the argument is double quoted, but the arguments are expanded single-quoted.

    The macros gt_CHECK_VAR_DECL, gt_CHECK_DECL, gl_MINMAX_IN_HEADER,
    gl_FLOATTYPE_SIGN_LOCATION are not public: all possible invocations are
    found in these *.m4 files. Therefore they are correct as is.

Well, the argument can be reversed. Therefore they can also use consistent quoting.

    The macro AC_LIB_HAVE_LINKFLAGS is meant to be called with literal
    arguments. Calling it with complex expressions is not supported. In
    particular, one of its arguments is 'testcode', which may contain
    array declarations. If you remove a level of quoting here, you introduce
    a bug.

You introduce a change, not a bug. It may be a good reason to let this one go, though.

3) Indentation:

-          AC_TRY_RUN([
+          AC_RUN_IFELSE([AC_LANG_SOURCE([[
  #include<stddef.h>
  #include<stdio.h>
  int main ()
  {
    return fopen ("conftest.sl/", "w") != NULL;
-}], [gl_cv_func_fopen_slash=yes], [gl_cv_func_fopen_slash=no],
+}]])], [gl_cv_func_fopen_slash=yes], [gl_cv_func_fopen_slash=no],

    Lines of code are not *that* expensive that it would warrant
      - opening two macro invocations on the same line, without closing
        the second one on the same line,

Well, this is customary M4 indentation (opening macros on the same line as its caller if they are the first argument).

The only change I'd make to Ralf's indentation would be to do like

}]])],
             [gl_cv_func_fopen_slash=yes],
             [gl_cv_func_fopen_slash=no]

      - putting 5 closing brackets/braces/parentheses in a row, like if
        you were programming Forth.

You mean Lisp? However, note that ]])] is quite common, it's only the first } that is additional.

Context is everything. If you see the gl_cv_func_fopen_slash assignment after it, you understand what is closed. And since this is C code without unmatched parentheses a la case, for a five line argument you can use electric parens or paren matching commands (such as, in vi/VIPER, the % command).

Paolo




reply via email to

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