When running 'gmake test' on my PHP6 tree on Solaris 10 (SPARC), I
noticed that a number of test failures were caused by the presence of
non-ASCII characters in function names etc.
For example:
sapi/cli/php tests/classes/__set__get_001.php
Setting [a] to 100
OK!
Getting [a]
Returning: 100
Setting [a] to 101
OK!
Getting [z]
Nothing!
Setting [z] to 1
Not OK!
object(�����f���)#1 (2) {
[u"n"]=>
int(1)
[u"x"]=>
array(3) {
[u"a"]=>
int(101)
[u"b"]=>
int(2)
[u"c"]=>
int(3)
}
}
The problem seems to be with how zstr values are passed to varargs functions.
Taking the above example, the following code in ext/standard/var.c is
what prints the line that is supposed to contain "object(setter)#1 (2)
{".
php_printf("%sobject(%v)#%d (%d) {\n", COMMON, class_name,
Z_OBJ_HANDLE_PP(struc), myht ? zend_hash_num_elements(myht) : 0);
where class_name is declared as
zstr class_name;
php_printf calls vspprintf which calls xbuf_format_converter which
retrieves the value of class_name using
UChar *u;
u = va_arg(ap, UChar *);
The Sun Studio compilers don't seem to like it when a vararg is passed
as a zstr union and then retrieved as a (UChar *). Specifying
class_name.v instead of class_name to php_printf fixes the problem.
This doesn't seem to be a problem on Ubuntu/gcc.
I searched for all occurrences of %v and %R in the PHP6 tree and added
a .v to all the zstr values passed to those functions. The patch is
here - http://bitbucket.org/arvi/arviq/src/tip/svn-zstr-varargs-patch.txt
Please could someone take a look and let me know if this is correct.
If so, then I'll do the same for %r as well.
Thanks,
Arvi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
