Re^4: Passing NULL pointer through XS without "Use of uninitialized value in subroutine entry"

Your version doesn't work with the usage I gave initially, that's what :-)

I agree there are bugs in this, but they are bugs that were present initially. Because this happens to be a very heavily used, very mission-critical piece of code, that unfortunately has no existing unit tests, I'm loathe to make anything more than the absolute minimal change to get rid of this warning message. For that reason what I did was to look at the generated C code and ensured that the only change was to add the particular required check against undef (the SvOK(tmp) check) to avoid the warning in this case.

Addressing each of your points:

This is incorrect. The SvROK check means that only references are accepted. I've verified that 123 and 'abc' are not accepted. The two that are references are accepted, and that is indeed a bug, albeit a preexisting one.
Indeed, a preexisting bug
Yes, that is what the current interface does and is expected for that usage.
No, but it's what gets generated by the original XS code

Can you explain to me exactly the difference between T_OBJECT and T_PTROBJ? I can't find anywhere in the perl docs that explains the standard typemaps, but maybe I'm not looking in the right place.

Comment on Re^4: Passing NULL pointer through XS without "Use of uninitialized value in subroutine entry"

Replies are listed 'Best First'.
Re^5: Passing NULL pointer through XS without "Use of uninitialized value in subroutine entry" by ikegami (Patriarch) on Aug 23, 2006 at 18:06 UTC
Can you explain to me exactly the difference between T_OBJECT and T_PTROBJ? `T_OBJECT` is not a standard type. It doesn't exist in the core typemap. (I checked 5.6.1, 5.8.0, 5.8.6 and 5.8.8). If you provided me with your module-specific typemap, I'll explain what it does. You should use `T_PTROBJ` or `T_PTRREF`, according to perlxs. For inputs of type `T_PTROBJ`, the XSUB calls the XS equivalent of `UNIVERSAL::isa` on the argument to make sure the arguemnt is defined and a blessed reference of the appropriate class or of a descendant of the appropriate class. Outputs of this type of blessed. For inputs of type `T_PTRREF`, the XSUB only checks if the argument is a reference. It doesn't care if the reference is blessed or not. Outputs of this type are not blessed. I've verified that 123 and 'abc' are not accepted. Only if `XSRETURN_UNDEF` returns immediately (as opposed to setting the return value). I don't know if it does, and you said you didn't know what `XSRETURN_UNDEF` does. Move `RETVAL = my_c_create_bar(foo);` into the "then" clause of the `if` to be safe.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Passing NULL pointer through XS without "Use of uninitialized value in subroutine entry"
by ikegami (Patriarch) on Aug 23, 2006 at 18:06 UTC

Can you explain to me exactly the difference between T_OBJECT and T_PTROBJ?

T_OBJECT is not a standard type. It doesn't exist in the core typemap. (I checked 5.6.1, 5.8.0, 5.8.6 and 5.8.8). If you provided me with your module-specific typemap, I'll explain what it does.

You should use T_PTROBJ or T_PTRREF, according to perlxs.

For inputs of type T_PTROBJ, the XSUB calls the XS equivalent of UNIVERSAL::isa on the argument to make sure the arguemnt is defined and a blessed reference of the appropriate class or of a descendant of the appropriate class. Outputs of this type of blessed.

For inputs of type T_PTRREF, the XSUB only checks if the argument is a reference. It doesn't care if the reference is blessed or not. Outputs of this type are not blessed.

I've verified that 123 and 'abc' are not accepted.

Only if XSRETURN_UNDEF returns immediately (as opposed to setting the return value). I don't know if it does, and you said you didn't know what XSRETURN_UNDEF does. Move RETVAL = my_c_create_bar(foo); into the "then" clause of the if to be safe.

[reply]
[d/l]
[select]