[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: format bug
Daniel Richard G.
Re: format bug
Thu, 31 May 2007 21:06:12 -0400
On Thu, 2007 May 31 13:23:28 -0600, Eric Blake wrote:
> > Leery of making "%c" == "%.1s". This behavior doesn't seem terribly useful.
> But it would match what /bin/printf does, and nobody complained about that
> being not terribly useful when it was standardized in POSIX.
Given the amount of griping that goes on about POSIX in general, I find
that difficult to believe.
Anyway, matching what printf(1) does is an advantageous property, but not
so much (IMHO) as to justify following every quirk. You could argue that
the longtime behavior of %c better matches the C semantic---which is
familiar to a lot more people, and is more authoritative on this than
> > Also, once the transition period is over, the only way to specify a
> > non-literal character will be via \NNN, \x or \u, yes? All of which require
> > an octal or hex argument. What would I do if I have an eval()---whose
> > result is decimal---and I want to convert the result to a character?
> eval() takes a second argument - if you are computing a value, it is just
> as easy to compute it in octal or hex to begin with. For example,
> format(`%b', `\0'eval(computation, `8'))
Okay, I forgot about eval()'s radix (and width) arguments. So that makes it
possible. But do you really think that e.g.
define(`codepoint', `8995')dnl Unicode "SMILE" character
format(`\u'eval(codepoint, `16', `4'))
is an improvement over
(I've been using a chr() composite implemented with %lc, which I thought
was extremely cool on finding that m4 supported it. Now I'm a bit miffed
that the latest CVS code no longer recognizes this...)
On a separate note, this point you mentioned earlier caught my notice:
> - - no portable way to convert a character to an integer short of a
> 255-element reverse-lookup table (you could use a forloop recursion
> construct, but be sure your iterator and quote characters are
> multi-character for the duration of the loop to avoid parse problems; hmm,
> maybe I should code this up and add it to the examples directory)
I've come up against this issue as well.
May I suggest borrowing a page from Perl, and adding a builtin like ord()?
That would be much more efficient than a lookup table, and it would be able
to handle multi-byte characters.
NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef?
EMAIL1 = address@hidden ## don't smell bad--- (/o|o\) /
EMAIL2 = address@hidden ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
(****** = site not yet online)