> > in spite of the warnings. Are the warnings a bug?
> It seems so. Would you be willing to file this report
> as a Savannah ticket?
Do not remove the warnings. They are not a bug.
Here is how .ie and .el work:
* .ie evaluates its condition "c" and pushes "not(c)" onto a
stack. Then, if "c" is true, it executes the rest of the
line, otherwise it simply discards it.
* .el pops a value "z" from the stack. If "z" is true, it
executes the rest of the line, otherwise it discards it.
Now consider again the code
.de mymac
.ie '\\$1'a' CASE a
.el .ie '\\$1'b' CASE b
.el .ie '\\$1'c' CASE c
.el CASE z
..
and imagine calling this as
.mymac a
Then, step by step, this is what happens:
1) First line: the condition evaluates to "true", so .ie
pushes "false" onto the stack. The stack now contains one
item. "CASE a" is output, since the condition was "true".
2) Second line: .el pops the previously pushed value "false"
off the stack. The stack is now empty. Since "false"
was popped, the rest of the line is discarded.
3) Third line: .el tries to pop a value off the stack,
but the stack is empty, therefore a warning is printed.
Since no "true" was popped, the rest of the line is
discarded.
4) Fourth line: .el tries to pop a value off the stack,
but the stack is still empty, therefore a warning is
printed. Since no "true" was popped, the rest of the
line is discarded.
So, superficially it might appear as if the code were doing the
right thing. But now imagine that .mymac was called as part of
a larger .ie branch. THEN THOSE TWO .el REQUESTS WILL POP VALUES
FROM THE STACK THAT MOST PROBABLY WERE NOT INTENDED FOR THEM.
With no warnings to indicate that the logic of .mymac was flawed
when called in isolation, imagine the frustration of trying to
debug the behavior of troff in that larger context under the
(wrong) assumption that .mymac was in fact correct.
