[Top][All Lists]

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

Re: format bug

From: Eric Blake
Subject: Re: format bug
Date: Thu, 31 May 2007 07:05:21 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070221 Thunderbird/ Mnenhy/

Hash: SHA1

Hello Gary,

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.

>> 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).

>  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.  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?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

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