[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Well, nothing to be really "concerned" about, mostly consistency. In a
> declaration, `()' has a different meaning than `(void)', but not in the
> definition. According to section 6.7.5.3 or ISO/IEC 9899:1999:
>
> 10 The special case of an unnamed
Hi Neil,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Why? Does () have any symptoms that we should be concerned about?
Well, nothing to be really "concerned" about, mostly consistency. In a
declaration, `()' has a different meaning than `(void)', but not in the
definition. According to section
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hello,
>
> Neil Jerram <[EMAIL PROTECTED]> writes:
>
>> Nice work, but it looks to me that PUSH_REF sets the value of the
>> (pstate->top)th element _before_ incrementing pstate->top. So
>> shouldn't your fix do the decrement first and then set the sl
Hello,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Nice work, but it looks to me that PUSH_REF sets the value of the
> (pstate->top)th element _before_ incrementing pstate->top. So
> shouldn't your fix do the decrement first and then set the slot to
> undefined?
Yes, you're perfectly right.
> (N
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> * print.c (EXIT_NESTED_DATA): Before popping from the stack,
> reset the value at its top. This fixes a reference leak.
Nice work, but it looks to me that PUSH_REF sets the value of the
(pstate->top)th element _before_ incrementing pstate
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> I may have struck that or something similar a while back. Mikael
> explained it was a reference held in the print data of the output
> port, or something. Used to detect cyclic structures, or something.
Thanks: you put me on the right track! So thi
