m4-discuss
[Top][All Lists]
Advanced

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

Re: format bug


From: Daniel Richard G.
Subject: Re: format bug
Date: 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 
printf(1).

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

        format(`%lc', codepoint)

?

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


--Daniel


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




reply via email to

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