Gregor N. Purdy <[EMAIL PROTECTED]> wrote:
> ..., but I didn't want to make
> 2 * N new .c files to get paranoid versions of the N core .c
> files now.
One safe core, built separately with its own Ops files ought to be
enough, IMHO.
> I thought about prederef a bit right before submitting this, and
> I think the prederef code path is a great place to do the checks.
Yep.
> In fact, I'm wondering if the prederef process shouldn't just do
> the paranoid checks always, since the point of its process is to
> make one slightly slower pass through things so that subsequent
> passes can get a speed boost. Maybe it won't be too much of a hit
> to leave PARANOID as a built-in part of it always.
I'd do simple checks always as register range ckecks. But more
complicated ones like decomposing keys and checking key register numbers
or constant table entries could be done only if the paranoid flag bit of
the prederef function is turned on.
>> While its seems legitimate to check P and S registers for
>> NULL, its suboptimal to generally disallow NULL registers. NULL PRegs
>> are in use e.g. for C<dlfunc> and if the code allows execution of dlfunc
>> (probably not but ...) a NULL value for the dl-handle is valid.
> Only 'in' S and P registers are being checked for NULLness.
> I looked at dlfunc, and I think the right code is being
> generated for PARANOID. Maybe you could post a code snippet
> to point out where it is wrong...
e.g. from src/parrot/languages/imcc/t/syn/pcc.t
.sym pmc NULL
null NULL
dlfunc FABS, NULL, "fabs", "dd"
Passing a NULL handle to dlfunc aka dlsym gets you functions of the main
program.
>> And finally composite keys may have registers too.
> I have to admit I don't know much about the way the keyed stuff
> works. It appeared in Parrot after my big push of effort. I've
> been wanting to integrate it into Jako as a way of learning how
> it works, but alas my supply of tuits has been very low for
> some time.
jit.c:263 ff has an example of getting registers out of keys.
> Regards,
> -- Gregor
leo
