[RfC] Testing for null
Juergen Boemmels
I'm curently playing around with open calls returning a PMCNULL
instead of a half valid IO-Object. But the main problem with that is
that there is currently no way for the byte-code to detect such a
case.
The if and unless ops call the get_boolean vtable method which throws
an internal exception.
As we can create a PMCNULL with the null_p op there should at least
be a way to test for a PMCNULL. Two possible solutions come to my mind
* A PMCNULL has false semantics. This may be done by letting
get_boolean return FALSE, or by adding a test to if_p_ic op:
if(!PMC_IS_NULL($1) && $1->vtable->get_boolean($1))
* Have a special op for this if_null and unless_null which exlusively
test for NULL.
Comments
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Melvin Smith
>I'm curently playing around with open calls returning a PMCNULL
>instead of a half valid IO-Object. But the main problem with that is
>that there is currently no way for the byte-code to detect such a
>case.
>The if and unless ops call the get_boolean vtable method which throws
>an internal exception.
>As we can create a PMCNULL with the null_p op there should at least
>be a way to test for a PMCNULL. Two possible solutions come to my mind
>
>* A PMCNULL has false semantics. This may be done by letting
> get_boolean return FALSE, or by adding a test to if_p_ic op:
> if(!PMC_IS_NULL($1) && $1->vtable->get_boolean($1))
>* Have a special op for this if_null and unless_null which exlusively
> test for NULL.
My intention for PMCNULL was to catch invalid interpreter state, or
invalid bytecode; cases which used to give us core dumps.
Explicitly returning PMCNULL and allowing tests on PMCNULL may
or may not fit into this, depending on your point of view. I'm not even
certain what my view of it is. Allowing ANY valid test on PMCNULL
seems to muddy the water by allowing it to actually be used.
The question is: should we allow a NULL register test
and would this replace Undef as the de facto way to return
"nothing". Probably the answer is "yes" but I'd like to hear Dan's
take on it.
-Melvin
Juergen Boemmels
[...]
> My intention for PMCNULL was to catch invalid interpreter state, or
> invalid bytecode; cases which used to give us core dumps.
>
> Explicitly returning PMCNULL and allowing tests on PMCNULL may
> or may not fit into this, depending on your point of view. I'm not even
> certain what my view of it is. Allowing ANY valid test on PMCNULL
> seems to muddy the water by allowing it to actually be used.
There is currently a way of creating such an object:
null P0
But you can't do anything with this object. If there are valid reasons
to create such an object, there should be a way to test for it.
> The question is: should we allow a NULL register test
> and would this replace Undef as the de facto way to return
> "nothing". Probably the answer is "yes" but I'd like to hear Dan's
> take on it.
There is currently no general Undef, only a PerlUndef, which warns if
used and morphs to a PerlInt when incremented. It might be best to
create a undef.pmc.
bye
Leopold Toetsch
> Hi,
> I'm curently playing around with open calls returning a PMCNULL
> instead of a half valid IO-Object. But the main problem with that is
> that there is currently no way for the byte-code to detect such a
> case.
C<defined> tests for PMCNULL too and is usable.
> * A PMCNULL has false semantics. This may be done by letting
> get_boolean return FALSE, or by adding a test to if_p_ic op:
> if(!PMC_IS_NULL($1) && $1->vtable->get_boolean($1))
Or the null.pmc gets a valid get_bool() vtable slot returning 0.
OTOH when PMCNULL is a real NULL, this will fail then.
> * Have a special op for this if_null and unless_null which exlusively
> test for NULL.
Probably better.
> boe
leo