I recently ran into a problem in m4 (1.4.16) when passing hex arguments to
the incr() and decr() builtins:
incr(0x4)
m4:incr.m4:1: non-numeric argument to builtin `incr'
I've checked the latest versions of the 1.4 and 1.6 branches and the issue
seems to stem from this line in numeric_arg() in builtin.c:
*valuep = strtol (arg, &endp, 10);
The radix is fixed as base-10.
I don't know if this is necessarily a bug since the POSIX and GNU docs are
vague about the acceptable arguments other than that they must be "numeric"
or "integers". It seems to me that all of the numeric formats supported by
eval() should also work with incr() and decr().
As a partial fix, the base in strtol() could be changed to 0 to get support
for octal and hex literals but that leaves binary and arbitrary bases
unsupported. At a quick glance it looks like eval_lex() could be used for
converting numeric arguments in all formats after a check for unary +/- at
the start of a string. The fix could be restricted to m4_incr() and
m4_decr() if there is concern about breaking legacy m4 code using other
builtins that call numeric_arg().
--
Kevin Thibedeau
