mje has asked for the wisdom of the Perl Monks concerning the following question:

I am trying to debug a problem in DBD::ODBC. DBD::ODBC which has an attribute named odbc_err_handler which when set to a subroutine reference gets called whenever there is an error. Unfortunately, when odbc_err_handler is reset to undef, the error handler still gets called. The actual C code fragment is: 
int
   dbd_db_STORE_attrib(dbh, imp_dbh, keysv, valuesv)
   SV *dbh;
imp_dbh_t *imp_dbh;
SV *keysv;
SV *valuesv;
{
   switch(pars->fOption)
   {
      case ODBC_ERR_HANDLER:
     bSetSQLConnectionOption = FALSE;

     /* This was taken from DBD::Sybase 0.21 */
     if(valuesv == &sv_undef) {
        imp_dbh->odbc_err_handler = NULL;
         } else if(imp_dbh->odbc_err_handler == (SV*)NULL) {
        imp_dbh->odbc_err_handler = newSVsv(valuesv);
     } else {
        sv_setsv(imp_dbh->odbc_err_handler, valuesv);
     }
     break;

[download]
I have verified that when I set $database_handle->{odbc_error_handler} it gets into the code above but always ends up in the else statement. The problem is that DBD::ODBC uses (if imp_dbh->odbc_error_handler) to test whether it should call the error handler and even after setting to undef, it is set. If I add the following to the start of the if it works: 
     if(!SvOK(valuesv)) {
        imp_dbh->odbc_err_handler = NULL;
         }

[download]
My problem is that I do not understand what the first 2 original if tests and following statements do and I though &sv_undef should be &PL_sv_undef anyway (not that this helps).

Replies are listed 'Best First'.
Re: testing for undef in perl XS code (in DBD::ODBC)
by salva (Canon) on Nov 05, 2007 at 22:44 UTC
    The right way to test for undef in XS code is using !SvOK(sv).

    PL_sv_undef is a perl scalar with the undef value, but it is not the only one. It is just for convenience, to not have to instantiate a new scalar on every place where an undef is required.

    sv_undef is a macro that expands to PL_sv_undef

[reply]
[d/l]
[select]
      I'm finding 
        if(valuesv == &sv_undef)

      [download]
      never tests true and 
      !SvOK(valuesv)

      [download]
      tests true when valuesv is undef - of course. What I'm not sure is what the original author might have meant by the first test above - perhaps it should have been SvOK in which case it was bug, perhaps something else.
[reply]
[d/l]
[select]
        I have a question about this: 
        use warnings;
use strict;

use Inline C => Config =>
    BUILD_NOISY => 1;

use Inline C => <<'EOC';

SV * create_undef() {
     return newSVsv(&PL_sv_undef);
} 

void is_defined(SV * x) {
     //x = &PL_sv_undef;
     x == &PL_sv_undef ? printf("Not defined\n") : printf("Defined\n")
+;
}

EOC

my $undef = create_undef();
is_defined($undef);

        [download]
        Note that $undef is created (by 'create_undef()') with the value &PL_sv_undef, and that the 'is_defined()' function then tests to see whether $undef == &PL_sv_undef. Amazingly, 'is_defined()' reports that $undef != &PL_sv_undef (by stating that $undef is defined).

        But if you uncomment that one line of C code that is excluded in the above script, then you find that $undef == &PL_sv_undef (as 'is_defined()' now states that $undef is undefined).

        I think we're dealing with the fact &PL_sv_undef is the value associated with a certain memory location, and that the value associated with a certain memory location changes from one function to the next. salva (or anyone else, for that matter), is that a valid approximation of what's happening ?

        Cheers,
        Rob
[reply]
[d/l]
[select]
        oh, I am pretty sure it is a bug!
[reply]

Back to Seekers of Perl Wisdom