Re: incorrect behavior in tparm

[Thomas Dickey]

On Thu, Jul 16, 2015 at 04:49:21PM -0700, address@hidden wrote:
> Hello.
> 
>    I've noticed that the ncurses implementation of tparm treat a few of the
> less common operators in ways that don't seem to be correct.  In particular:

perhaps (I'm wary of trusting the O'Reilly book too much, since I'm aware
that terminfo continued to evolve for several years after the book).
 
>      * The %O operator is implemented in terms of C's short-circuiting
>      || operator (and similarly %A is implemented 
>         in terms of &&). As a result the stack is left in differing
>         states depending on the inputs. For instance,
>         interpreting "%{1}%?%p1%p2%O%t%{0}%+%;%d" with with arguments 0
>         and 1 gives the suprising result 
>         of "0". The "Termcap and Terminfo" book describes %O as "Pop the
>         top two values and push TRUE if either is
>         true, FALSE if both are false". 

thanks - I see the problem...
 
>      * The %l operator outputs the (stringized) value of the length of
>      its operand rather than pushing this value 
>         onto the stack. Here, the "Termcap and Terminfo" book says: "Pop
>         the top of the stack and push the its 
>         string length". Seems like there's a word or two missing there,
>         but it seems to agree that the length belongs 
>         on the stack.

ncurses' terminfo(5) says
       %l   push strlen(pop)

which matches X/Open...

The value which is popped is a string, and spop checks that the value
was given as a string -- otherwise it returns an empty string.  There's
no type-conversion.

(tparm accepts both long integers and strings).
I'm unclear where "stringized" comes in.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

signature.asc
Description: Digital signature