>> +m4_define([_AC_TYPE_INT_BODY], >> +[ AS_LINENO_PUSH([$[]1]) >> + AC_CACHE_CHECK([for int$[]2_t], [$[]3], >> + [AS_VAR_SET([$[]3], [no]) >> + for ac_type in 'int$[]2_t' 'int' 'long int' \ > > Should that be "int$[]2_t", rather than '', since we want shell expansion of > $2 > to take place in creating $ac_type?
Indeed. >> +# _AC_TYPE_INT(NBITS) >> +# ------------------- >> +AC_DEFUN([_AC_TYPE_INT], > > A comment describing this m4 macro would be nice. (And several other macros > touched by this patch). Ok. >> +[AC_REQUIRE_SHELL_FN([ac_func_c_find_intX_t], >> + [AS_FUNCTION_DESCRIBE([ac_func_c_find_intX_t], [LINENO BITS], >> + [Finds a signed integer type with width BITS, setting a cache variable >> + accordingly.])], >> + [$0_BODY])]dnl > > Is this really C specific? Can C++ or Objective C use it? In other words, > do > we want _c_ in the macro name? I mimicked the cache variable name. I wonder if we need an AC_LANG_PUSH/POP pair in the user, in fact. >> m4_bmatch([$1], [^\(8\|32\|64\)$], > > Unrelated to the patch, but what happened to 16? No _UINT16_T needed, apparently... Paolo
