Dan and Nick --
> >[and I did laugh out loud when I finally realised what cunning tricks it is
> >doing to replace the deref function with the pointer to the opcode function,
> >and return the same address so that the run loop calls the real function at
> >that point]
>
> It is rather clever, is
At 01:59 AM 1/1/2002 +, Nicholas Clark wrote:
>On Mon, Dec 31, 2001 at 06:19:22PM -0500, Dan Sugalski wrote:
> > At 11:10 PM 12/31/2001 +, Nicholas Clark wrote:
> > >But is the correct correction to swap the parameters
> > >
> > >((op_func_prederef_t)*pc_prederef) (interpreter, pc_prederef
On Mon, Dec 31, 2001 at 06:19:22PM -0500, Dan Sugalski wrote:
> At 11:10 PM 12/31/2001 +, Nicholas Clark wrote:
> >But is the correct correction to swap the parameters
> >
> >((op_func_prederef_t)*pc_prederef) (interpreter, pc_prederef);
> >
> >or to change the typedef?
>
> The functions all
At 11:10 PM 12/31/2001 +, Nicholas Clark wrote:
>But is the correct correction to swap the parameters
>
>((op_func_prederef_t)*pc_prederef) (interpreter, pc_prederef);
>
>or to change the typedef?
The functions all take the interpreter argument second. First arg is a
pointer to an opcode_t,
I'm attempting to make a start on annihilating the warnings picked up by all
the new gcc stricture, but it seems that there are actually some existing
compiler warnings about pointer confusion.
Aside from the hundreds in core_ops.c and core_ops_prederef.c (which may be
the same cause) there is an
