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

Somewhat inspired by your suggestion, and taking some things from the original generated C code, I've currently got something like this:

struct bar*
create_event(foo_sv)
  SV* foo_sv
  struct type_foo* foo = NULL;
  CODE:
    if ( SvROK(foo_sv)) {
      SV *tmp = (SV*) SvRV(foo_sv);
      if ( SvOK (tmp)) {
        foo = (struct type_foo*) SvIV(tmp);
      }
    } else {
      warn( "Foo::create_bar() -- foo is not an SV reference" );
      XSRETURN_UNDEF;
    }

    RETVAL = my_c_create_bar(foo);
  OUTPUT:
    RETVAL
[download]

which successfully avoids the warning message I was getting originally. Unfortunately, this is one of those bits of code someone else wrote originally and didn't write tests for, so now I need to go and actually write some tests to make sure this works right.

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

Replies are listed 'Best First'.
Re^3: Passing NULL pointer through XS without "Use of uninitialized value in subroutine entry" by ikegami (Patriarch) on Aug 22, 2006 at 23:33 UTC
What's the problem with what I provided? You've introduced so many bugs! Your function now accepts any scalar as an argument. `create_bar(123);` is accepted. `create_bar('abc');` is accepted. `create_bar(['a', 'b']);` is accepted. `create_bar({key => 'val'});` is accepted. If the argument is a reference, it will unconditionally be treated as an object of type type_foo, even if it isn't even an object. `warn` gets executed when you pass undef. Do you even know what `XSRETURN_UNDEF` does? I don't, but I'm pretty sure it's not used properly. You should be using type T_PTROBJ if you didn't accept undef, so you should base your code on `T_PTROBJ`. Updated	[reply] [d/l] [select]
Re^4: Passing NULL pointer through XS without "Use of uninitialized value in subroutine entry" by kscaldef (Pilgrim) on Aug 23, 2006 at 17:15 UTC
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.	[reply]
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]