According to Gary V. Vaughan on 5/31/2007 5:19 AM:
Meanwhile, m4's format builtin, for the past 17 years, has handled %c as
a conversion from integer to character (with ASCII, format(%c,9) results
in TAB, [[...]]
Gratuitously breaking 17 years of accumulated GNU m4 input seems like a
bad idea to me. What do other m4 implementations do?
format is a GNU extension. Not even BSD m4 provides this extension.
There is no precedent, which is why I think making format more like
printf(1) has merit.
True enough wrt to extensions. I still wonder how much existing GNU m4 client
code (inadvertently or otherwise) relies on the current behaviour...
Any objections to this approach?
Not if it is only turned on in POSIXLY_CORRECT mode, at least in the
stable branch.
But that seems wrong. Since format is a GNU extension, POSIXLY_CORRECT
should not affect it. And I have already ensured that the changes I am
proposing to the branch do not affect the expansion of existing valid
strings; all it does is add new expansions that were previously
undocumented and invalid (therefore no one could have been using them),
and add warnings on certain expansions that are not compatible with printf(1).
...but, as long as you're sure others' existing m4 code will not regress
(I'm looking at autotools here really), then I'm okay with the change.
For 2.0, using a posixy approach by default is okay,
provided there is no code in recent autoconf releases that barfs at the
change...
For the branch, %c would continue to behave in the old clunky way, only it
would now also emit a warning (but not affect exit status, so as not to
kill autoconf). And to make sure, we could even do this: if the string
looks like an integer, use the old semantics with a warning; otherwise,
use the first character of the string, so that it is not until 2.1 where
%c can finally fully match printf by always using the first character of
the string.
Sounds good!
However, I think the amount of autoconf code that relies on
the old %c syntax is minimal, particularly since it is so confusing
because it is currently different than printf(1). Maybe it is also worth
improving the command line to add a --warnings=level option that can
silence the new warnings, without impacting other warnings?
fine to me.
PGP.sig