On Sunday 22 June 2003 16:38, you wrote:
> As far as I can see this has the potential to break scripts. If you can
> explain to us why the cases where an object is now returned will not break
> any existing scripts, then I don't think anybody would have any problem
> with it going into 4.3.3.
If this is the problem, I can explain why it won't break any script. One of
the reasons I introduced the valueretrieval global (and the two new PHP
functions are only wrappers for modifying/reading this global!) was to not
break backwards compatibility.
The old way to read a SNMP value was:
---
#ifdef HAVE_NET_SNMP
snprint_value(buf, sizeof(buf), vars->name, vars->name_length, vars);
#else
sprint_value(buf,vars->name, vars->name_length, vars);
#endif
---
Depending on the SNMP action (get, walk, etc.) (char *)buf was
- returned with RETVAL_STRING(),
- written to an array via add_next_index_string() or
- written to an assosiative array via add_assoc_string()
Little has changed with the new code as long as the valueretrievel global is
set to 0 (which is the default!):
---
MAKE_STD_ZVAL(snmpval);
php_snmp_getvalue(vars, snmpval TSRMLS_CC);
---
Which is, when following the php_snmp_getvalue() function:
---
if (SNMP_G(valueretrieval) == 0) {
#ifdef HAVE_NET_SNMP
snprint_value(buf, sizeof(buf), vars->name, vars->name_length, vars);
#else
sprint_value(buf,vars->name, vars->name_length, vars);
#endif
ZVAL_STRING(snmpval, buf, 1);
return;
}
---
Depending on the SNMP action (get, walk, etc.) (zval *)snmpval is
- copied to return_value (with *return_value = *snmpval;
zval_copy_ctor(return_value);)
- written to an array via add_next_index_zval() or
- written to an assosiative array via add_assoc_zval()
The point is that with valueretrieval set to 0, the SNMP value is still
retrieved with snprint_value()/sprint_value(). I've been really really
careful with this...
Of course the statement "The way SNMP values are retrieved has been changed"
isn't quite correct. The way SNMP values are retrieved has been made
*adjustable*. Sorry if this has been misleading.
Cheers, Johann
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
