Re: format bug

[Gary V. Vaughan]

On 31 May 2007, at 14:05, Eric Blake wrote:

Hello Gary,

Hi Eric,

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, [[...]]

bad idea to me.  What do other m4 implementations do?

Gratuitously breaking 17 years of accumulated GNU m4 input seems like a

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.

code (inadvertently or otherwise) relies on the current behaviour...

True enough wrt to extensions. I still wonder how much existing GNU m4 client

Any objections to this approach?

Not if it is only turned on in POSIXLY_CORRECT mode, at least in the
stable branch.

proposing to the branch do not affect the expansion of existing valid
strings; all it does is add new expansions that were previously

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 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,

change...

provided there is no code in recent autoconf releases that barfs at the

the string.

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

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

improving the command line to add a --warnings=level option that can
silence the new warnings, without impacting other warnings?

because it is currently different than printf(1). Maybe it is also worth

Nah, that looks like over-engineering.  Let's just grep through the dev
and stable branches of autotools for calls to format, and if there are

fine to me.

Cheers,
        Gary
--
  ())_.              Email me: [EMAIL PROTECTED]
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

no occurrences that will be regressed, outputting a regular warning seems

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
M4-discuss mailing list
M4-discuss@gnu.org
http://lists.gnu.org/mailman/listinfo/m4-discuss