[PHP-DEV] patch for trivial ZE2 leaks
I found memleaks in the current HEAD. A Patch for this issue attached.
$ php -r class foo {}
/home/koizumi/src/php5/Zend/zend_hash.c(198) : Freeing 0x400C1034 (64 bytes), s
cript=-
/home/koizumi/src/php5/Zend/zend_hash.c(176) : Actual location (location was rel
ayed)
Last leak repeated 5 times
/home/koizumi/src/php5/Zend/zend_compile.c(3454) : Freeing 0x400C0ED4 (44 bytes
), script=-
/home/koizumi/src/php5/Zend/zend_compile.c(2201) : Freeing 0x400C0CD0 (296 byte
s), script=-
/home/koizumi/src/php5/Zend/zend_language_scanner.l(1107) : Freeing 0x400C0C94
(4 bytes), script=-
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.388
diff -u -r1.388 zend_compile.c
--- Zend/zend_compile.c 6 Mar 2003 23:45:50 - 1.388
+++ Zend/zend_compile.c 7 Mar 2003 15:29:42 -
@@ -2207,6 +2207,7 @@
zend_error(E_COMPILE_ERROR, Cannot use '%s' as class name as it is
reserved, class_name-u.constant.value.str.val);
}
+ new_class_entry-type = ZEND_USER_CLASS;
new_class_entry-name = class_name-u.constant.value.str.val;
new_class_entry-name_length = class_name-u.constant.value.str.len;
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-I18N] Help: Sablotron and Shift-jis
It works for me. See the attached example. Anyway, you don't have to
crosspost your question to [EMAIL PROTECTED], which is for developing
php internals and irrelevant for such user questions.
Hope this helps
Moriyoshi
Michel Sahyoun [EMAIL PROTECTED] wrote:
Does anyone have an example of using XSLT with Sablotron to transform and
XML document containing Shift-jis encoded characters?
I keep getting the following error message: Illegal Character for Encoding
'Shift-jis'
I am using the latest from snap.php.net and sablotron 0.97 FullPack with
iconv, and Javascript.
In my php file, I call xslt_set_encoding($xsltHandle, 'Shift-jis');
My xsl file has xsl:output method=xml omit-xml-declaration=yes
encoding=Shift-jis /
My XML file has: ?xml version=1.0 encoding=Shift-jis ?
Am I doing something wrong? Is the encoding name misspelled? Anything else I
could check?
Thanks,
Michel
--
PHP Internationalization Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
?xml version=1.0 encoding=Shift_JIS ?
demo
Íaha/ Í
¢Ðdef/¢Ð
¤Óghi/¤Ó
/demo
?php
$xp = xslt_create();
xslt_set_encoding($xp, Shift_JIS);
xslt_process($xp, test.xml.txt, test.xsl.txt, result.xml);
?
?xml version=1.0 encoding=Shift_JIS?
\ xmlns=http://www.w3.org/TR/xhtml1/strict;
\vf content=aha/
\vf content=def/
\vf content=ghi/
/\
?xml version=1.0 encoding=Shift_JIS ?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:output method=xml indent=yes encoding=Shift_JIS /
xsl:template match=demo
\
\vf content={ Í} /
\vf content={¢Ð} /
\vf content={¤Ó} /
/\
/xsl:template
/xsl:stylesheet
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Modifying PHP variables in C
You should use zval_ptr_dtor() to dispose the old value. Note the old value won't actually be freed as long as any reference to the variable is alive. for example, zval *ary1, *ary2; /* $ary1 = array(); */ ALLOC_INIT_ZVAL(ary1); array_init(ary1); /* $ary2 = array(); */ ALLOC_INIT_ZVAL(ary2); array_init(ary2); /* $ary1['key'] = 123; */ add_assoc_long_ex(ary1, key, sizeof(key), 123); /* $ary2['key'] = 456; */ add_assoc_long_ex(ary2, key, sizeof(key), 456); /* $ary1 = $ary2 */ zval_add_ref(ary2); zval_ptr_dtor(ary1); ary1 = ary2; Moriyoshi John Lim [EMAIL PROTECTED] wrote: Hi, I'm porting some PHP code to C, and was hoping that someone can help me. I have 2 variables $oldarray and $newarray that both hold arrays and want to set $oldarray = $newarray; I suppose i have to dispose of $oldarray before i set it to $newarray. I'm not sure what is the best way, so i did this. zval **oldarray,*newarray; zval_add_ref(newarray); convert_to_null_ex(oldarray); *oldarray = newarray; Would this work? Secondly is there a better way. Thanks again. John Lim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH][ZE1] (resend) fix for bug #19943
Hi,
Could anyone review this patch again? (I sent this one before the release
of 4.3.0 actually.) The patch is against ZE1 and addresses memleaks that
occur when brackets are used to access an element in a string like below.
patch:
http://marc.theaimsgroup.com/?l=php-devm=103654899426422q=p3
snippet:
?php
$ar = array();
for ($count = 0; $count 10; $count++) {
$ar[$count]= $count;
$ar[$count]['idx'] = $count;
}
for ($count = 0; $count 10; $count++) {
echo $ar[$count]. -- .$ar[$count]['idx'].\n;
}
?
Regards,
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tie'ing variables
George Schlossnagle [EMAIL PROTECTED] wrote: Having this sort of functionaility in general would be great. I know you can affect this with objects via overload, but it is useful for scalars and arrays and streams as well. It is pretty 'magical' though. Then how about allowing access to object properties via square brackets like ECMA-Script? Though this will definitely add much more complexity to the Engine... Moriyoshi George On Saturday, March 1, 2003, at 11:26 AM, Sterling Hughes wrote: I was wondering if it might be possible to tie these arrays to a function (if you don't understand that, look at Perl for a definition). One could populate them as an overloaded object, and then array accesses would work - I guess. But I would prefer a cleaner mechanism. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] patch for binary-safe strip_tags()
Hi, Attached is the patch for binary-safe strip_tags(). Although it doesn't appear to be harmful anyhow, I think it needs review since it modifies rather sensitive part. Any objections? Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] patch for binary-safe strip_tags()
Oops, forgot to attach it...
Moriyoshi
On Tue, Feb 25, 2003 at 03:14:58AM +0900, Moriyoshi Koizumi wrote:
Hi,
Attached is the patch for binary-safe strip_tags().
Although it doesn't appear to be harmful anyhow, I think it needs
review since it modifies rather sensitive part.
Any objections?
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
? ext/standard/filters.c.next
Index: ext/standard/php_string.h
===
RCS file: /repository/php4/ext/standard/php_string.h,v
retrieving revision 1.71
diff -u -r1.71 php_string.h
--- ext/standard/php_string.h 11 Feb 2003 22:47:26 - 1.71
+++ ext/standard/php_string.h 24 Feb 2003 17:17:23 -
@@ -129,7 +129,7 @@
PHPAPI char *php_str_to_str(char *haystack, int length, char *needle,
int needle_len, char *str, int str_len, int *_new_length);
PHPAPI char *php_trim(char *c, int len, char *what, int what_len, zval *return_value,
int mode TSRMLS_DC);
-PHPAPI void php_strip_tags(char *rbuf, int len, int *state, char *allow, int
allow_len);
+PHPAPI size_t php_strip_tags(char *rbuf, int len, int *state, char *allow, int
allow_len);
PHPAPI int php_char_to_str(char *str, uint len, char from, char *to, int to_len, pval
*result);
PHPAPI void php_implode(zval *delim, zval *arr, zval *return_value);
PHPAPI void php_explode(zval *delim, zval *str, zval *return_value, int limit);
Index: ext/standard/string.c
===
RCS file: /repository/php4/ext/standard/string.c,v
retrieving revision 1.359
diff -u -r1.359 string.c
--- ext/standard/string.c 18 Feb 2003 18:11:34 - 1.359
+++ ext/standard/string.c 24 Feb 2003 17:17:24 -
@@ -3299,6 +3299,7 @@
zval **str, **allow=NULL;
char *allowed_tags=NULL;
int allowed_tags_len=0;
+ size_t retval_len;
switch (ZEND_NUM_ARGS()) {
case 1:
@@ -3320,8 +3321,8 @@
}
convert_to_string_ex(str);
buf = estrndup(Z_STRVAL_PP(str), Z_STRLEN_PP(str));
- php_strip_tags(buf, Z_STRLEN_PP(str), NULL, allowed_tags, allowed_tags_len);
- RETURN_STRING(buf, 0);
+ retval_len = php_strip_tags(buf, Z_STRLEN_PP(str), NULL, allowed_tags,
allowed_tags_len);
+ RETURN_STRINGL(buf, retval_len, 0);
}
/* }}} */
@@ -3555,7 +3556,7 @@
swm: Added ability to strip ?xml tags without assuming it PHP
code.
*/
-PHPAPI void php_strip_tags(char *rbuf, int len, int *stateptr, char *allow, int
allow_len)
+PHPAPI size_t php_strip_tags(char *rbuf, int len, int *stateptr, char *allow, int
allow_len)
{
char *tbuf, *buf, *p, *tp, *rp, c, lc;
int br, i=0, depth=0;
@@ -3751,6 +3752,8 @@
efree(tbuf);
if (stateptr)
*stateptr = state;
+
+ return (size_t)(rp - rbuf);
}
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: daggilli
Please make your request for a cvs account at http://www.php.net/cvs-php.php. (Not here) Moriyoshi David Gillies [EMAIL PROTECTED] wrote: Ignore previous subject line, username request is daggilli --- David Gillies [EMAIL PROTECTED] wrote: I'd like to request CVS access to the PEAR/PECL effort so I can contribute a couple of modules I've written. Requested username: daggilli David Gillies San Jose Costa Rica __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Contributing to PHP - how?
David Gillies [EMAIL PROTECTED] wrote: At present all I have is a tiny module that groks tzfile(5) files to get you historical offsets from UTC, and another one that exposes about 80 or so As for tzfile module, probably Pierre wants some sort of tzinfo parser in his extension. Better off getting in touch with him. http://news.php.net/article.php?group=php.devarticle=94275 Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI long options
[EMAIL PROTECTED] (Marcus Börger) wrote: Hi, the patch below allows long option names such as --version and --help what eases the use of php especially when used on the command line. And it fixes the problem with duplicate error messages if arguments to command line are erroneous. http://marcus-boerger/php/ext/cli-getopt.diff.txt +1 from me if you are sure it doesn't break BC. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] (resend) fix for bug #21600 and #22231
Hi,
Could anyone who has ZE karma review this patch again?
Thanks,
Moriyoshi
Index: Zend/zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.316.2.3
diff -u -r1.316.2.3 zend_execute.c
--- Zend/zend_execute.c 31 Dec 2002 16:22:59 - 1.316.2.3
+++ Zend/zend_execute.c 13 Jan 2003 00:34:32 -
@@ -265,27 +265,37 @@
variable_ptr_ptr = EG(uninitialized_zval_ptr);
/* } else if (variable_ptr==EG(uninitialized_zval) || variable_ptr!=value_ptr) {
*/
} else if (variable_ptr_ptr != value_ptr_ptr) {
- variable_ptr-refcount--;
- if (variable_ptr-refcount==0) {
- zendi_zval_dtor(*variable_ptr);
- FREE_ZVAL(variable_ptr);
- }
+ if (variable_ptr != value_ptr) {
+ variable_ptr-refcount--;
+ if (variable_ptr-refcount==0) {
+ zendi_zval_dtor(*variable_ptr);
+ FREE_ZVAL(variable_ptr);
+ }
- if (!PZVAL_IS_REF(value_ptr)) {
- /* break it away */
- value_ptr-refcount--;
- if (value_ptr-refcount0) {
- ALLOC_ZVAL(*value_ptr_ptr);
- **value_ptr_ptr = *value_ptr;
- value_ptr = *value_ptr_ptr;
- zendi_zval_copy_ctor(*value_ptr);
+ if (!PZVAL_IS_REF(value_ptr)) {
+ /* break it away */
+ value_ptr-refcount--;
+ if (value_ptr-refcount0) {
+ ALLOC_ZVAL(*value_ptr_ptr);
+ **value_ptr_ptr = *value_ptr;
+ value_ptr = *value_ptr_ptr;
+ zendi_zval_copy_ctor(*value_ptr);
+ }
+ value_ptr-refcount = 1;
+ value_ptr-is_ref = 1;
+ }
+ *variable_ptr_ptr = value_ptr;
+ value_ptr-refcount++;
+ } else {
+ if (value_ptr == EG(uninitialized_zval_ptr)) {
+ ALLOC_ZVAL(value_ptr);
+ value_ptr-type = IS_NULL;
+ value_ptr-refcount = 1;
+ value_ptr-is_ref = 1;
+ *variable_ptr_ptr = *value_ptr_ptr = value_ptr;
+ value_ptr-refcount++;
}
- value_ptr-refcount = 1;
- value_ptr-is_ref = 1;
}
-
- *variable_ptr_ptr = value_ptr;
- value_ptr-refcount++;
} else {
if (variable_ptr-refcount1) { /* we need to break away */
SEPARATE_ZVAL(variable_ptr_ptr);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] please apply to PHP_4_3 branch: servlet build fix
Hi, Where's the patch? Perhaps the attachment was eliminated by the list program. Try suffixing it with .txt or inlining it. Thanks Moriyoshi Giuseppe Tanzilli - CSF [EMAIL PROTECTED] wrote: hi, committed some fixes to build the servlet sapi, but have no permission to commit this small fix, please apply to 4_3 branch thanks a log Giuseppe -- --- Giuseppe Tanzilli [EMAIL PROTECTED] CSF Sistemi srl phone ++39 0775 7771 Via del Ciavattino Anagni FR Italy -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] writing test cases
Kai Schröder [EMAIL PROTECTED] wrote: In addition to my yesterday's mail I've found a new broken test: tests/lang/bug21961.phpt Fixed. Thanks for the notification. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] writing test cases
I got the same idea in the first place and so I didn't append SKIPIF section. I simply don't know much about Windows testruns. Moriyoshi Harald Radi [EMAIL PROTECTED] wrote: that's not true guys, PHP4 is in the PHP_4_3 branch and if you don't explicitely commit the tests to that branch they won't be there. HEAD is PHP5. there's no need for comparing versions or whatever except if you want to make one test work differently for both php versions. harald Moriyoshi Koizumi [EMAIL PROTECTED] schrieb im Newsbeitrag news:20030204015827W=3'[EMAIL PROTECTED]... Kai Schröder [EMAIL PROTECTED] wrote: In addition to my yesterday's mail I've found a new broken test: tests/lang/bug21961.phpt Fixed. Thanks for the notification. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question on bug list
[EMAIL PROTECTED] (Marcus Börger) wrote: Wouldn't it be nice if one could attach himself to a bug and receive an email on every new message to that bug? And then how am i informed about new bugs? Is there a mailing list for that? Currently i read the bug-summary-list.. I was thinking of a similar bug db feature too, though my idea seems rather user-oriented. IMO it would be nice if a commenter could make a choice to receive notifications by every new comment. I suppose that would be useful if you wanted feedbacks from multiple users. In a QA member's point of view, I don't see that much need for my favourite bugs because my MUA is just doing enough. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deep compare: nesting level too deep
On Sat, Jan 25, 2003 at 01:00:53AM +0100, Vaclav Dvorak wrote: When I try to compare two child objects, PHP says: Fatal error: Nesting level too deep - recursive dependency?. Well, yes, it _is_ a recursive dependency, but I don't see why PHP could not compare those objects anyway? Isn't it possible to tell whether two names reference the same variable? In fact, I'm comparing two references to the very same object, so the comparison could stop right there and not compare any members of the object. Are you trying it with ZE2? Compare those objects with === not ==. You'll get the exact result you've expected to see, I suppose. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach nastiness with references (bug #21702)
On Wed, Jan 22, 2003 at 04:12:18PM +0100, Vaclav Dvorak wrote: Moriyoshi Koizumi wrote: I tried to answer this question in the bug report page. [...] 1) Each time before entering a foreach loop, php first tries to make a copy of the array being iterated. 2) In case the array variable is either referenceing another variable or referenced by another variable, no copy is made here and the original array is used instead. Because of this behaviour, the original's internal array pointer increases in the loop eventually. Yes, I understand this. What I don't understand is WHY is it so? Why is foreach handling references specially? Why is your point 2) there? Oh, I found this issue was pointed out pretty long time ago. - Bug #5052 http://bugs.php.net/5052 - Bug #5270 (deleted?) http://news.php.net/article.php?group=php.devarticle=22668 http://news.php.net/article.php?group=php.devarticle=22672 http://news.php.net/article.php?group=php.devarticle=22673 It seems that the commit I mentioned in the previous mail was just for those problem reports. As no much discussion took place there, all I can guess from them is there was already a fear of breaking BC. Anyway, please search the database first, in order not to post the same kind of bug twice. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach nastiness with references (bug #21702)
Hi,
?php
$a = array(1,2,3);
#$r = $a;
echo current before foreach: . current($a) . br\n;
foreach($a as $b) {
echo - value in cycle: . $b . br\n;
echo -- current in cycle: . current($a) . br\n;
}
echo current before foreach: . current($a) . br\n;
?
Try it, and the delete the hash mark and try again.
I tried to answer this question in the bug report page.
To say more precisely, foreach statement always makes use of a copy of
the given array instead of the original itself unless the array is a
reference or has a reference.
What I meant by this is
1) Each time before entering a foreach loop, php first tries to make a copy of
the array being iterated.
2) In case the array variable is either referenceing another variable or
referenced by another variable, no copy is made here and the original
array is used instead. Because of this behaviour, the original's internal
array pointer increases in the loop eventually.
And once a variable is referenced by another, both are treated as reference
from then on. For example,
?php
$test = array();
$test['a'] = 'a';
$test['b'] = $test['a'];
debug_zval_dump($test);
?
This script produces following output:
array(2) refcount(2){
[a]=
string(1) a refcount(2)
[b]=
string(1) a refcount(2)
}
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] foreach nastiness with references (bug #21702)
Just FYI, here's a relevant commit made by Andi two years ago: http://cvs.php.net/diff.php/Zend/zend_execute.c?r1=1.222r2=1.223ty=h Moriyoshi John Coggeshall [EMAIL PROTECTED] wrote: Ah, I understand now... This perhaps in a documentation problem then after all, as there is no way to change this behavior cleanly that I can see... What about making a copy of the array and all of the references associated with that array instead of just using the real array? Just a thought. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request data filter
It looks like a mess indeed, and there seems a thought that encoding conversion and variable registration should be separated into two phases. However doing so doesn't make sense because some of multibyte characters contains [, ], or = and they cannot be handled properly in the ordinary query parser. Therefore Rasmus's sugestion sounds quite logical to me. Moriyoshi On Wed, Jan 15, 2003 at 04:52:58PM -0800, Rasmus Lerdorf wrote: In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler hooks, however it gets messy when you throw mbstring into the mix as that extension also uses those hooks. The cleanest way I can think of doing this is to add a function pointer to SAPI for the filtering function that will be run right before the php_register_variable_safe() call. Currently we are always calling php_url_decode() on the data before registering the variable, so I propose that we make php_url_decode() the default that an extension can then override. Anybody see any reason not to make this simple change? Without that I will need to somehow detect whether mbstring is present and then filter the data after it has already been registered by mbstring's treat_data/post_handler hooks. That's a big mess! -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Wed, Jan 15, 2003 at 06:36:20PM +0100, Harald Radi wrote: iirc the reason why i changed it to unsigned was that actually the zend engine treated it as unsigned everywhere but in that particular struct. i also remember that i discussed that with andi and that he agreed to change this in the ze2 cvs module and that the extensions should be *fixed*. i agree that it doesn't make any sense to mix types. changing it to uint means to fix all the extensions, changing it to int means to fix the engine (and not just to revert my patch). While I think changing the len field to unsigned or size_t itself is a good idea, it is also the case that there're certain security risks that should have been considered. IMHO as long as no one is likely to agree the idea to either modify Z_STRLEN macro or make a new macro Z_SAFE_STRLEN so that it would force the engine to bail out when the length exceeds the maximam value of signed integer (or possibly signed short) like Sascha said, more priority has to be taken on fixing the engine over the former because it hardly seems the change has been known by the numerous extension developers. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] fix for bug #21600
Attached is a patch for bug #21600.
This problem is caused by unnecessary zval destruction performed when
trying to assign a value that is originated from the same zval.
Moriyoshi
Index: Zend/zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.316.2.3
diff -u -r1.316.2.3 zend_execute.c
--- Zend/zend_execute.c 31 Dec 2002 16:22:59 - 1.316.2.3
+++ Zend/zend_execute.c 13 Jan 2003 00:34:32 -
@@ -265,27 +265,37 @@
variable_ptr_ptr = EG(uninitialized_zval_ptr);
/* } else if (variable_ptr==EG(uninitialized_zval) || variable_ptr!=value_ptr) {
*/
} else if (variable_ptr_ptr != value_ptr_ptr) {
- variable_ptr-refcount--;
- if (variable_ptr-refcount==0) {
- zendi_zval_dtor(*variable_ptr);
- FREE_ZVAL(variable_ptr);
- }
+ if (variable_ptr != value_ptr) {
+ variable_ptr-refcount--;
+ if (variable_ptr-refcount==0) {
+ zendi_zval_dtor(*variable_ptr);
+ FREE_ZVAL(variable_ptr);
+ }
- if (!PZVAL_IS_REF(value_ptr)) {
- /* break it away */
- value_ptr-refcount--;
- if (value_ptr-refcount0) {
- ALLOC_ZVAL(*value_ptr_ptr);
- **value_ptr_ptr = *value_ptr;
- value_ptr = *value_ptr_ptr;
- zendi_zval_copy_ctor(*value_ptr);
+ if (!PZVAL_IS_REF(value_ptr)) {
+ /* break it away */
+ value_ptr-refcount--;
+ if (value_ptr-refcount0) {
+ ALLOC_ZVAL(*value_ptr_ptr);
+ **value_ptr_ptr = *value_ptr;
+ value_ptr = *value_ptr_ptr;
+ zendi_zval_copy_ctor(*value_ptr);
+ }
+ value_ptr-refcount = 1;
+ value_ptr-is_ref = 1;
+ }
+ *variable_ptr_ptr = value_ptr;
+ value_ptr-refcount++;
+ } else {
+ if (value_ptr == EG(uninitialized_zval_ptr)) {
+ ALLOC_ZVAL(value_ptr);
+ value_ptr-type = IS_NULL;
+ value_ptr-refcount = 1;
+ value_ptr-is_ref = 1;
+ *variable_ptr_ptr = *value_ptr_ptr = value_ptr;
+ value_ptr-refcount++;
}
- value_ptr-refcount = 1;
- value_ptr-is_ref = 1;
}
-
- *variable_ptr_ptr = value_ptr;
- value_ptr-refcount++;
} else {
if (variable_ptr-refcount1) { /* we need to break away */
SEPARATE_ZVAL(variable_ptr_ptr);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Sat, Jan 11, 2003 at 05:56:23PM -0500, Ilia A. wrote:
On January 11, 2003 06:03 pm, Moriyoshi Koizumi wrote:
On Sat, Jan 11, 2003 at 11:38:20PM +0100, [EMAIL PROTECTED] wrote:
Sorry but just a thought, in that line:
if (argc 1 (int)Z_STRLEN_P(return_value) len / 2) {
Does this mean we now always need to cast the result of the
Z_STRLEN_P/Z_STRLEN_PP macros to int? That seems pretty annoying and not to
producing ugly code.
That's all due to the change of len field in zvalue_value union.
Do you mean this kind of warnings should be fixed
not by adding ugly casts but by restoring the structure like ZE1?
(ZE1)
typedef union _zvalue_value {
long lval; /* long value */
double dval;/* double value */
struct {
char *val;
int len;
} str;
HashTable *ht; /* hash table value */
zend_object obj;
} zvalue_value;
(ZE2)
typedef union _zvalue_value {
long lval; /* long value */
double dval;/* double value */
struct {
char *val;
zend_uint len;
} str;
HashTable *ht; /* hash table value */
/* struct {
zend_class_entry *ce;
HashTable *properties;
} obj;
*/
zend_object_value obj;
} zvalue_value;
I think uint'ifying len field is a good idea though.
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Sat, Jan 11, 2003 at 11:59:49PM +0100, Sascha Schumann wrote: Does this mean we now always need to cast the result of the Z_STRLEN_P/Z_STRLEN_PP macros to int? That seems pretty annoying and not to producing ugly code. Certainly not. What kind of warnings was the compiler (which one?) issuing? Please look at the win32/ZE2 compile log in http://snaps.php.net/ Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c
On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote:
As many past security advisories have shown, signedness
issues are the frequent cause for severe vulnerabilities in
software (recent examples include MySQL, OpenBSD kernel).
Actually codes like below produce vulnerble runtimes because
the length of string is expected to be a positive integer value...
int maxlen;
...
if ((int)Z_STRLEN_P(length) maxlen) {
RETURN_FALSE;
}
memcpy(allocated_buf, Z_STRVAL_P(length), Z_STRLEN_P(length));
Any objections?
No objection from me.
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Stream filters, converters and i18n.
Hi, I renewed the base64 filter yesterday to use newly implemented converter facility. This enables you to apply arbitrary filter operations to a writer and a reader respectively. But this also makes some complexity for users. How can we select these operations? Currently there seems to be just two options: either by filter name or by parameter. As for the first option, according to Wez's explanation in his code, /* We allow very simple pattern matching for filter factories: * if charset.utf-8/sjis is requested, we search first for an exact * match. If that fails, we try charset.*. * This means that we don't need to clog up the hashtable with a zillion * charsets (for example) but still be able to provide them all as filters */ I can make one generic filter factory and name it as converter.*. In this case, you could choose operations by the filter name like converter.base64-encode/base64-decode and you could pass parameters to each converter(filter) via the third optional parameter of stream_filter_append() or stream_filter_prepend(). For example, stream_filter_append($fp, convert.quoted-printable-encode/base64-decode, base64-decode.ignore-eof=1,quoted-printable-encode.soft-line-break=1); where the first part in the filter name specifies the output filter and the second part specifies the input filter. Otherwise I might set up a factory named convert which takes at least two parameters delimited by /. You could specify the operation like stream_filter_append($fp, convert, base64-encode:flush-on-close,forbid-seek/base64-decode:forbid-seek); Now what do you think of this? I need a decision. By the way, I find the converter is quite portable and also important for i18n stuff, I'd like to make the converter independent to the filter code. Any comments on this? Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c
Hi, On Tue, Jan 07, 2003 at 12:12:15PM -0800, Sara Golemon wrote: Speaking of filter string.base64 I have an issue with its parity. string.base64 will encode on write and decode on read... What if the user wants the other way round? Is the expected behavior even obvious from the name alone? Should there be two separate filters? string.base64-encode string.base64-decode with each doing the same opperation on either read or write? Agreed. I hit the same problem you mentioned while implementing iconv encoding conversion filter. I should have made the filters capable of working in the opposite way. But would it rather be preferred to switch the filter function by parameters given to the factory, than to have two similar filters? Then the problem is there's no unified way to handle those parameters. Actually it will do for me to make my own handler, but I see it will definitely end up in great inconsistency. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] string functions
I mentioned a similar inconsistency of range() parameters in the past and pointed out a possible BC breaking issue raised by your recent patch on array.c in HEAD. http://news.php.net/article.php?group=php.devarticle=91489 http://news.php.net/article.php?group=php.devarticle=92910 I meant no tricks by is_numeric_string() were needed and the passed string values should always be regarded as a single character, just as it was. Moriyoshi On Sun, Jan 05, 2003 at 01:40:31PM -0500, Ilia A. wrote: While converting the functions inside string.c to the new parameter parsing API and doing some general cleanup, I've come across an interesting 'feature'. Three string functions: stristr(), strstr() and strpos() have peculiar way of handling non string values passed as 'needle'. Instead of converting the needle to a string they instead convert it to an integer and search for a character equivalent to that integer. This behavior causes a problem such as strstr(abc123, 1) returning false rather then returning 123 as one may expect. Because this behavior is not documented, I believe we could safely change it back to the behavior listed in the manual and the one defined in the function's prototype. The con of this approach is that it may break scripts that really on the undocumented behavior, therefor I propose that this change would only go into the 4.4/5.0 branch at which point people will expect small behavioral changes. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new iconv functions
Hi, I've just committed a patch which I mentioned in the previous mail. http://news.php.net/article.php?group=php.devarticle=92027 But I'm not sure if the function naming really conforms to the standard. If it annoys you, please let me know. Regards, Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c /ext/standard/tests/array range.phpt
Added support for float values and handling of numeric values being passed as strings. Is this change likely to cause backwards compatibility issues? Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /ext/standard array.c
Andrei Zmievski wrote:
Was this fix entirely necessary? It didn't seems like a showstopper bug.
First, I apologize I didn't ask you for permission before committing my
patch.
Actually it might not be a showstopper, but I believe this should be
fixed before the release,
because it's a bug that causes segfault in usual usage.
Moriyoshi
On Wed, 25 Dec 2002, Moriyoshi Koizumi wrote:
moriyoshi Wed Dec 25 15:00:14 2002 EDT
Modified files: (Branch: PHP_4_3)
/php4/ext/standard array.c
Log:
Fixed bug #21182
Index: php4/ext/standard/array.c
diff -u php4/ext/standard/array.c:1.199.2.9 php4/ext/standard/array.c:1.199.2.10
--- php4/ext/standard/array.c:1.199.2.9 Fri Dec 6 12:36:25 2002
+++ php4/ext/standard/array.c Wed Dec 25 15:00:12 2002
@@ -21,7 +21,7 @@
+--+
*/
-/* $Id: array.c,v 1.199.2.9 2002/12/06 17:36:25 iliaa Exp $ */
+/* $Id: array.c,v 1.199.2.10 2002/12/25 20:00:12 moriyoshi Exp $ */
#include php.h
#include php_ini.h
@@ -1429,18 +1429,17 @@
array_init(return_value);
if (Z_TYPE_PP(zlow)==IS_STRING Z_TYPE_PP(zhigh)==IS_STRING) {
- char *low, *high;
- convert_to_string_ex(zlow);
- convert_to_string_ex(zhigh);
- low = Z_STRVAL_PP(zlow);
- high = Z_STRVAL_PP(zhigh);
- if (*low*high) {
- for (; *low = *high; (*low)--) {
-add_next_index_stringl(return_value, low, 1, 1);
+ unsigned char low, high;
+ low = *((unsigned char *)Z_STRVAL_PP(zlow));
+ high = *((unsigned char *)Z_STRVAL_PP(zhigh));
+
+ if (lowhigh) {
+ for (; low = high; (low)--) {
+add_next_index_stringl(return_value, (char *)low, 1, 1);
}
} else {
- for (; *low = *high; (*low)++) {
-add_next_index_stringl(return_value, low, 1, 1);
+ for (; low = high; (low)++) {
+add_next_index_stringl(return_value, (char *)low, 1, 1);
}
}
} else {
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
-Andrei http://www.gravitonic.com/
C combines all the power of assembly language with
all the ease of use of assembly language -- trad
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /ext/standard array.c
Andrei Zmievski [EMAIL PROTECTED] wrote: On Fri, 27 Dec 2002, Moriyoshi Koizumi wrote: Andrei Zmievski wrote: Was this fix entirely necessary? It didn't seems like a showstopper bug. First, I apologize I didn't ask you for permission before committing my patch. Actually it might not be a showstopper, but I believe this should be fixed before the release, because it's a bug that causes segfault in usual usage. I thought segfault happened only on HEAD, not on the branch? Sorry, it was just my mistake of fact. So is the fix really desirable? Moriyoshi -Andrei http://www.gravitonic.com/ * Power corrupts. Atomic power corrupts atomically. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure
As far as I've looked into this problem, absense of Content-Encoding
field in the response headers, apparently a side effect of the patch of
rev 1.138 for main/SAPI.c, results in un-inflated output on the clients.
Because the patch was designed only to work with statically linked zlib
module, it causes link failure on unix build and prevents part of the code
responsible for sending the required headers from being compiled properly
on Windows build (due to the lack of HAVE_ZLIB definition) in case the
extension is built as shared. This was confirmed by comparing the browser
outputs of the following two scripts.
?php /* script A (should give incorrect result) */
echo test;
?
?php /* script B (should be OK) */
Header(Content-Encoding: gzip);
Header(Vary: Accept-Encoding);
echo test;
?
Besides this patch doesn't seem to accomplish its purpose completely, as
there would be no way at all to stop output_compression once the output
buffer is flushed either intentionally or automatically.
?php /* script C */
echo str_repeat(abcd, 1023);
/* the next line actually switches off output compression */
ini_set('zlib.output_compression', 0);
?
?php /* script D */
echo str_repeat(abcd, 1024);
/* no way to stop output compression at this point */
ini_set('zlib.output_compression', 0);
?
Therefore I think the modified part should be reverted for now, unless
there is a better way to fulfill the requirement (see bug #16109).
BTW since when did I become a output guy ? :)
Moriyoshi
Wez Furlong [EMAIL PROTECTED] wrote:
This needs one of you output guys to resolve it.
Andrei mentioned something about making the final release before 1st
Jan, so if you can, please get your coding-butts in gear :)
--Wez.
On 22 Dec 2002 [EMAIL PROTECTED] wrote:
ID: 21139
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Windows
PHP Version: 4.3.0RC4
New Comment:
Verified on Windows, with Apache or Apache2.
-- HTTP response dump of the following script --
?php echo abcde; ?
-- Apache_1.3.27 --
HTTP/1.1 200 OK
Date: Sun, 22 Dec 2002 18:06:53 GMT
Server: Apache/1.3.27 (Win32) PHP/4.4.0-dev
X-Powered-By: PHP/4.4.0-dev
Connection: close
Content-Type: text/html
(correctly gzip-encoded content)
-- Apache_2.0.43 --
HTTP/1.1 200 OK
Date: Sun, 22 Dec 2002 18:06:15 GMT
Server: Apache/2.0.43 (Win32) PHP/4.4.0-dev
Last-Modified: Sun, 22 Dec 2002 17:59:26 GMT
ETag: 45a2-1b-e744bab1
Accept-Ranges: bytes
Content-Length: 27
Connection: close
Content-Type: application/x-httpd-php
br /
bWarning/b: (null)() [a
href='http://www.php.net/ref.outcontrol'ref.outcontrol/a]: Cannot
change zlib.output_compression - headers already sent in bUnknown/b
on line b0/bbr /
abcde
Previous Comments:
[2002-12-21 19:27:53] [EMAIL PROTECTED]
I can confirm this bug on Windows + Apache + zlib.output_compression in
.htaccess.
If zlib.output_compression is set to on from php.ini it works. It only
doesn't work if set from .htaccess.
[2002-12-21 17:48:30] [EMAIL PROTECTED]
I have just installed latest php 4.3 on linux and windows.
I use the same directory and therefore .htaccess files for
apache/mod_php on both platforms.
When i enable enable output compression with ini setting
php_value zlib.output_compression On
in .htaccess the linux version works as expected but the
windows version fails. Sometimes i receive errors with
access violations. Sometimes i can downlowd the result
but when rename the resulting file to .gz i can open it and
as you might expect it contains the correct result. And
sometime i see the encoding result presented in the browser
and then i cannot save and view it although the gzip header
seems correct.
marcus
--
Edit this bug report at http://bugs.php.net/?id=21139edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure
Edin Kadribasic [EMAIL PROTECTED] wrote: Isn't the solution as simple as changing the #ifdef to include COMPILE_DL_ZLIB in the checks, or is this another situation where the zlib extension should be compiled into the distribution itself? Is there a problem with doing that in the win32 build Edin? (it seems that the unix build will also have the same problems if zlib is built as a shared extension - there was even a bug report today about related issues). One of the solutions for the windows build is to compile zlib module into php4ts.dll statically. In that way all the problems go away and its a nice module to have built-in anyway. I have a patch ready and a test build of php4ts.dll at http://snaps.php.net/~edink/php4ts.dll-zlib.zip I've checked your test build, and it works fine as for Apache-1.3.27. But it still fails with Apache2... this seems another apache2filter problem. Anyway this solution sounds like a quickest and most reasonable way. Moriyoshi Edin P.S. Make sure to remove extension=php_zlib.dll from your php.ini -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC4: ground rules
Andrei Zmievski [EMAIL PROTECTED] wrote:
Moriyoshi,
I appreciate your effort here, but it seems that while this approach is
more flexible, it is also bound to have more complicated. I have decided
to apply Philip's patch for 4.3.0.
I think my patch is too complicated to be included in 4.3.0 release too,
and there is still room for the discussion whether to prepare a special
ini entry like php_auth_exposure for those variables.
Moriyoshi
On Sat, 21 Dec 2002, Moriyoshi Koizumi wrote:
Ohh, it seems we have been working on the same patch simultaneously :)
Attached is my version of fix for bug #20441, which adopts a new ini entry
php_auth_exposure so that administrators can selectively expose auth
information to the clients regardless of safe_mode settings.
Possible values are:
- php_auth_exposure=user
Only PHP_AUTH_USER is exposed.
- php_auth_exposure=pw
Only PHP_AUTH_PW is exposed
- php_auth_exposure=user,pw
Both PHP_AUTH_USER and PHP_AUTH_PW are exposeed
Hope this helps.
Moriyoshi
Philip Olson [EMAIL PROTECTED] wrote:
Attatched is a patch that essentially goes back
to 4.2.3 behavior except the external auth will not
be available with PHP in safe mode. REMOTE_USER
exists regardless.
It seems some people also wanted an ini option, I don't
know how to do that! :)
References for this patch:
http://bugs.php.net/20441
http://cvs.php.net/diff.php/php4/sapi/apache/mod_php4.c?r1=1.132r2=1.133
On a related note, I'm curious why PHP_AUTH_TYPE does
not exist, only the variable AUTH_TYPE does (for me).
PHP_AUTH_TYPE has been documented forever, not sure if
it used to exist but various parts of PHP4 source make
it seem like it should.
Regards,
Philip Olson
p.s. Thanks to Wez and Steph for teaching me not to fear
the source.
On Fri, 20 Dec 2002, Andrei Zmievski wrote:
Everyone,
I have just released 4.3.0RC4. Despite the quote in my signature, I am
determined to keep this one the very last final RC of the interminable
4.3.0 development cycle. Towards that end, I will closely monitor the
CVS commits and revert any that do not satisfactorily explain what
critical or showstopper bug they are fixing. I am aware that
PHP_AUTH_USER issue raises certain concerns, but no one apparently could
make a patch. If, however, one appears very soon, I may consider it a
special one and apply it for 4.3.0.
-Andrei http://www.gravitonic.com/
The time from now until the completion
of the project tends to become constant. -- Douglas Hartree
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.520
diff -u -r1.520 main.c
--- main/main.c 16 Dec 2002 15:43:52 - 1.520
+++ main/main.c 21 Dec 2002 06:17:30 -
@@ -112,6 +112,9 @@
static void php_build_argv(char *s, zval *track_vars_array TSRMLS_DC);
+static PHP_INI_MH(OnUpdate_php_auth_exposure);
+#define PHP_EXPOSE_AUTH_USER 0x0001
+#define PHP_EXPOSE_AUTH_PW 0x0002
static char *short_track_vars_names[] = {
_POST,
@@ -275,6 +278,7 @@
STD_PHP_INI_ENTRY(output_handler, NULL,
PHP_INI_PERDIR|PHP_INI_SYSTEM, OnUpdateString, output_handler,
php_core_globals, core_globals)
STD_PHP_INI_BOOLEAN(register_argc_argv, 1,
PHP_INI_PERDIR|PHP_INI_SYSTEM, OnUpdateBool, register_argc_argv,
php_core_globals, core_globals)
STD_PHP_INI_BOOLEAN(register_globals, 0,
PHP_INI_PERDIR|PHP_INI_SYSTEM, OnUpdateBool, register_globals,
php_core_globals, core_globals)
+ STD_PHP_INI_ENTRY(php_auth_exposure, none,
PHP_INI_SYSTEM, OnUpdate_php_auth_exposure, php_auth_exposure,
php_core_globals, core_globals)
#if PHP_SAFE_MODE
STD_PHP_INI_BOOLEAN(safe_mode,1,
PHP_INI_SYSTEM, OnUpdateBool, safe_mode,
php_core_globals, core_globals)
#else
@@ -1191,6 +1195,7 @@
SG(request_info).argv=(char **)NULL;
PG(connection_status) = PHP_CONNECTION_NORMAL;
PG(during_request_startup) = 0;
+ PG(php_auth_exposure) = 0;
CG(zend_lineno) = 0;
@@ -1378,10 +1383,12 @@
}
/* PHP Authentication support */
- if (SG(request_info).auth_user) {
+ if ((PG(php_auth_exposure) PHP_EXPOSE_AUTH_USER)
+ SG(request_info).auth_user) {
php_register_variable(PHP_AUTH_USER, SG(request_info).auth_user,
array_ptr
Re: [PHP-DEV] RC4: ground rules
Hi, Possible values are: - php_auth_exposure=user Only PHP_AUTH_USER is exposed. - php_auth_exposure=pw Only PHP_AUTH_PW is exposed - php_auth_exposure=user,pw Both PHP_AUTH_USER and PHP_AUTH_PW are exposeed Moriyoshi, have you considered using constants here instead of strings? For example: - php_auth_exposure=AUTH_EXPOSE_USER Only PHP_AUTH_USER is exposed. - php_auth_exposure=AUTH_EXPOSE_PW Only PHP_AUTH_PW is exposed - php_auth_exposure=AUTH_EXPOSE_USER | AUTH_EXPOSE_PW Both PHP_AUTH_USER and PHP_AUTH_PW are exposeed It resembles the style used by error reporting, which will be less confusing for novices. At first I thought of using constants like you mentioned, but I decided to not do so in my patch because I don't want to pollute the namespace with such trivial constants that are likely to be used only in ini settings. There is no difference here, both are strings anyway. And the latest option AUTH_EXPOSE_USER | AUTH_EXPOSE_PW wont work in an httpd.conf file. Also, this is NOT the style we have in php.ini. I don't see any valid point to use this thing. I don't think this entry needs to be able to be toggled in per-dir settings. Moriyoshi Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c
Andi Gutmans [EMAIL PROTECTED] wrote: At 01:28 PM 12/19/2002 +, Wez Furlong wrote: Actually, it does seem valid to me; streams based on FILE* are not registered in the persistent list, so does it make sense to have the associated resources registered as persistent resources when they will get cleaned up by the engine at request shutdown? If these are per-request constants then you are correct and the patch was OK. I thought these were constants which survive requests. Well, only in cli are the constants STDIN, STDOUT, and STDERR registered. So can I commit the patch again? Moriyoshi Andi --Wez. On Wed, 18 Dec 2002, Andi Gutmans wrote: I don't like these voodoo patches. I think if the stream is destroyed twice that should be solved and not the constant itself. Unless you have a good reason please revert your patch and talk to Wez about fixing this properly. Thanks, Andi - ic.flags = CONST_CS | CONST_PERSISTENT; + ic.flags = CONST_CS; -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RC4: ground rules
Ohh, it seems we have been working on the same patch simultaneously :)
Attached is my version of fix for bug #20441, which adopts a new ini entry
php_auth_exposure so that administrators can selectively expose auth
information to the clients regardless of safe_mode settings.
Possible values are:
- php_auth_exposure=user
Only PHP_AUTH_USER is exposed.
- php_auth_exposure=pw
Only PHP_AUTH_PW is exposed
- php_auth_exposure=user,pw
Both PHP_AUTH_USER and PHP_AUTH_PW are exposeed
Hope this helps.
Moriyoshi
Philip Olson [EMAIL PROTECTED] wrote:
Attatched is a patch that essentially goes back
to 4.2.3 behavior except the external auth will not
be available with PHP in safe mode. REMOTE_USER
exists regardless.
It seems some people also wanted an ini option, I don't
know how to do that! :)
References for this patch:
http://bugs.php.net/20441
http://cvs.php.net/diff.php/php4/sapi/apache/mod_php4.c?r1=1.132r2=1.133
On a related note, I'm curious why PHP_AUTH_TYPE does
not exist, only the variable AUTH_TYPE does (for me).
PHP_AUTH_TYPE has been documented forever, not sure if
it used to exist but various parts of PHP4 source make
it seem like it should.
Regards,
Philip Olson
p.s. Thanks to Wez and Steph for teaching me not to fear
the source.
On Fri, 20 Dec 2002, Andrei Zmievski wrote:
Everyone,
I have just released 4.3.0RC4. Despite the quote in my signature, I am
determined to keep this one the very last final RC of the interminable
4.3.0 development cycle. Towards that end, I will closely monitor the
CVS commits and revert any that do not satisfactorily explain what
critical or showstopper bug they are fixing. I am aware that
PHP_AUTH_USER issue raises certain concerns, but no one apparently could
make a patch. If, however, one appears very soon, I may consider it a
special one and apply it for 4.3.0.
-Andrei http://www.gravitonic.com/
The time from now until the completion
of the project tends to become constant. -- Douglas Hartree
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.520
diff -u -r1.520 main.c
--- main/main.c 16 Dec 2002 15:43:52 - 1.520
+++ main/main.c 21 Dec 2002 06:17:30 -
@@ -112,6 +112,9 @@
static void php_build_argv(char *s, zval *track_vars_array TSRMLS_DC);
+static PHP_INI_MH(OnUpdate_php_auth_exposure);
+#define PHP_EXPOSE_AUTH_USER 0x0001
+#define PHP_EXPOSE_AUTH_PW 0x0002
static char *short_track_vars_names[] = {
_POST,
@@ -275,6 +278,7 @@
STD_PHP_INI_ENTRY(output_handler, NULL,
PHP_INI_PERDIR|PHP_INI_SYSTEM, OnUpdateString, output_handler,
php_core_globals, core_globals)
STD_PHP_INI_BOOLEAN(register_argc_argv, 1,
PHP_INI_PERDIR|PHP_INI_SYSTEM, OnUpdateBool, register_argc_argv,
php_core_globals, core_globals)
STD_PHP_INI_BOOLEAN(register_globals, 0,
PHP_INI_PERDIR|PHP_INI_SYSTEM, OnUpdateBool, register_globals,
php_core_globals, core_globals)
+ STD_PHP_INI_ENTRY(php_auth_exposure, none,
+PHP_INI_SYSTEM, OnUpdate_php_auth_exposure, php_auth_exposure,
+php_core_globals, core_globals)
#if PHP_SAFE_MODE
STD_PHP_INI_BOOLEAN(safe_mode,1,
PHP_INI_SYSTEM, OnUpdateBool, safe_mode,
php_core_globals, core_globals)
#else
@@ -1191,6 +1195,7 @@
SG(request_info).argv=(char **)NULL;
PG(connection_status) = PHP_CONNECTION_NORMAL;
PG(during_request_startup) = 0;
+ PG(php_auth_exposure) = 0;
CG(zend_lineno) = 0;
@@ -1378,10 +1383,12 @@
}
/* PHP Authentication support */
- if (SG(request_info).auth_user) {
+ if ((PG(php_auth_exposure) PHP_EXPOSE_AUTH_USER)
+ SG(request_info).auth_user) {
php_register_variable(PHP_AUTH_USER, SG(request_info).auth_user,
array_ptr TSRMLS_CC);
}
- if (SG(request_info).auth_password) {
+ if ((PG(php_auth_exposure) PHP_EXPOSE_AUTH_PW)
+ SG(request_info).auth_password) {
php_register_variable(PHP_AUTH_PW, SG(request_info).auth_password,
array_ptr TSRMLS_CC);
}
}
@@ -1820,6 +1827,66 @@
}
/* }}} */
#endif
+
+/* {{{ OnUpdate_php_auth_exposure */
+static PHP_INI_MH(OnUpdate_php_auth_exposure)
+{
+ char *comp, *p1;
+ int eos;
+ long val = 0;
+ int sp_cnt;
+
+ comp = NULL;
+
+ p1 = new_value;
+ eos = 0;
+
+ do {
+ if (*p1 == '\0') {
+ eos = 1;
+
Re: [PHP-DEV] Re: #20993 [Ver]:Elementvaluechangeswithoutasking
Melvyn Sopacua [EMAIL PROTECTED] wrote:
--snip
OK so that's a deep copy. As much as I understand the motivation I don't
think this should be done. It'll slow down lots of things in PHP. I think
this should be solved by documentation.
Yes, according to my trivial benchmark, my patch puts a considerable
weight on the ZendEngine, to run twice as slowly as the current runtime in
the worst case. Seems no way, but I suppose it also sounds a reasonable
penalty of using references.
Actually - the natural 'feeling' with references is speed increases - not
slowdowns,
since one expects a 'pointer', rather than a copy.
Is there a way to warn when such a refstatement is detected, without
causing slowdowns?
Then try the new patch. It prints out notices in such cases.
--
Benchmark results (the script used for this test is the same as the one
attached in my previous mail)
[Unmodified]
1: 0.166993
2: 0.099101
3: 0.219380
4: 0.094828
[After applying the new patch]
1: 0.189953
2: 0.099915
3: 0.238101
4: 0.095103
--
Moriyoshi
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: Zend/zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.316.2.2
diff -u -r1.316.2.2 zend_execute.c
--- Zend/zend_execute.c 17 Nov 2002 22:00:32 - 1.316.2.2
+++ Zend/zend_execute.c 18 Dec 2002 16:08:38 -
@@ -65,6 +65,7 @@
static void zend_extension_statement_handler(zend_extension *extension, zend_op_array
*op_array TSRMLS_DC);
static void zend_extension_fcall_begin_handler(zend_extension *extension,
zend_op_array *op_array TSRMLS_DC);
static void zend_extension_fcall_end_handler(zend_extension *extension, zend_op_array
*op_array TSRMLS_DC);
+static int check_array_contains_ref(zval **ppz);
#define RETURN_VALUE_USED(opline) (!((opline)-result.u.EA.type EXT_TYPE_UNUSED))
@@ -1816,6 +1817,9 @@
} else if (PZVAL_IS_REF(*param)) {
zend_assign_to_variable_reference(NULL, get_zval_ptr_ptr(EX(opline)-result, EX(Ts),
BP_VAR_W), param, NULL TSRMLS_CC);
} else {
+ if (check_array_contains_ref(param)) {
+ zend_error(E_NOTICE, Array
+passed to %s() (argument #%d) contains referenced element(s) which may result in
+unexpected behaviours, get_active_function_name(TSRMLS_C),
+EX(opline)-op1.u.constant.value.lval);
+ }
zend_assign_to_variable(NULL,
EX(opline)-result, NULL, *param, IS_VAR, EX(Ts) TSRMLS_CC);
}
}
@@ -2480,4 +2484,23 @@
}
}
zend_error(E_ERROR, Arrived at end of main loop which shouldn't happen);
+}
+
+static int _zval_ref_check(zval **p, void *flag)
+{
+ if ((*p)-is_ref) {
+ *(int *)flag = 1;
+ } else {
+ *(int *)flag = check_array_contains_ref(p);
+ }
+ return ZEND_HASH_APPLY_KEEP;
+}
+
+static int check_array_contains_ref(zval **ppz)
+{
+ int flag = 0;
+ if ((*ppz)-type == IS_ARRAY) {
+ zend_hash_apply_with_argument((*ppz)-value.ht, (apply_func_arg_t)
+_zval_ref_check, (void *)flag TSRMLS_CC);
+ }
+ return flag;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20993 [Ver]: Elementvaluechangeswithoutasking
Andi Gutmans [EMAIL PROTECTED] wrote: At 12:49 AM 12/17/2002 +0900, Moriyoshi Koizumi wrote: Andi Gutmans [EMAIL PROTECTED] wrote: I don't understand what you're doing here. Are you actually separating on every assignment and doing a deep copy? What I'm trying to do in my patch can be divided into two phases. In the first phase, it checks whether the array contains any referenced elements (of course it does nothing and return SUCCESS if the passed zval is a non-array value). If such an element exists, then entering the second phase, separates the array zval and duplicates each referenced element while it doesn't make copies, but only increments the refcount for non-referenced elements. OK so that's a deep copy. As much as I understand the motivation I don't think this should be done. It'll slow down lots of things in PHP. I think this should be solved by documentation. Yes, according to my trivial benchmark, my patch puts a considerable weight on the ZendEngine, to run twice as slowly as the current runtime in the worst case. Seems no way, but I suppose it also sounds a reasonable penalty of using references. Moriyoshi Andi Moriyoshi Andi At 04:09 PM 12/15/2002 +0900, Moriyoshi Koizumi wrote: Oops, the patch was wrong as the runtime occationally segfaults in a case like: ?php $a = 0; $a = $a; /* is_ref=1, refcount=1 */ ? Attached is the revised patch. Please try it out. And the result of a tiny benchmark follows: [Before patching] 1: 0.263245 2: 0.142505 3: 0.328045 4: 0.137149 [After patching] 1: 0.273811 2: 0.141965 3: 0.699429 4: 0.137010 Moriyoshi My proposal, was based on 2 things: fix or document. I'm sure Zeev/Andi had a good reason not to always separate, and that probably is performance. IF this impacts overall performance very negatively, then maybe the better choice is to document it. I'll try the patch though. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20993 [Ver]: Element valuechangeswithoutasking
--snip And the result of a tiny benchmark follows: [Before patching] 1: 0.263245 2: 0.142505 3: 0.328045 4: 0.137149 [After patching] 1: 0.273811 2: 0.141965 3: 0.699429 4: 0.137010 What's 1,2,3 and 4? Have a look at the attachment 'bm.php.txt'. Moriyoshi Moriyoshi My proposal, was based on 2 things: fix or document. I'm sure Zeev/Andi had a good reason not to always separate, and that probably is performance. IF this impacts overall performance very negatively, then maybe the better choice is to document it. I'll try the patch though. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20993 [Ver]: Element valuechangeswithoutasking
Andi Gutmans [EMAIL PROTECTED] wrote: I don't understand what you're doing here. Are you actually separating on every assignment and doing a deep copy? What I'm trying to do in my patch can be divided into two phases. In the first phase, it checks whether the array contains any referenced elements (of course it does nothing and return SUCCESS if the passed zval is a non-array value). If such an element exists, then entering the second phase, separates the array zval and duplicates each referenced element while it doesn't make copies, but only increments the refcount for non-referenced elements. Moriyoshi Andi At 04:09 PM 12/15/2002 +0900, Moriyoshi Koizumi wrote: Oops, the patch was wrong as the runtime occationally segfaults in a case like: ?php $a = 0; $a = $a; /* is_ref=1, refcount=1 */ ? Attached is the revised patch. Please try it out. And the result of a tiny benchmark follows: [Before patching] 1: 0.263245 2: 0.142505 3: 0.328045 4: 0.137149 [After patching] 1: 0.273811 2: 0.141965 3: 0.699429 4: 0.137010 Moriyoshi My proposal, was based on 2 things: fix or document. I'm sure Zeev/Andi had a good reason not to always separate, and that probably is performance. IF this impacts overall performance very negatively, then maybe the better choice is to document it. I'll try the patch though. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] uniqid
Hi, [EMAIL PROTECTED] (Marcus Börger) wrote: First: Uniqid test (tests/strings/001.phpt) failes for cygwin because the time for gettimeofday() is only updated once per second. I suggest we should change the test to use more entropy. Second: We should consider more entropy being default even though it is slower. I recognised this problem some time ago. We could use the alternative of gettimeofday() implemented in win32/time.c instead of the one that comes from the cygwin library. Third: the function is available even when HAVE_GETTIMEOFDAY is not available. This should be changed (is on out todo) or the function should return a unique value for such platforms, too. If we have to make it independent of time functions in those platforms which lack the function, it matters how we can supply enough entropy to it. Do you have any idea for this? Fourth: We should split ./tests/strings/001.phpt. One for the string functions and one for uniqid(). +1 Moriyoshi marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20993 [Ver]: Element value changeswithoutasking
Oops, the patch was wrong as the runtime occationally segfaults
in a case like:
?php
$a = 0;
$a = $a; /* is_ref=1, refcount=1 */
?
Attached is the revised patch. Please try it out.
And the result of a tiny benchmark follows:
[Before patching]
1: 0.263245
2: 0.142505
3: 0.328045
4: 0.137149
[After patching]
1: 0.273811
2: 0.141965
3: 0.699429
4: 0.137010
Moriyoshi
My proposal, was based on 2 things: fix or document. I'm sure Zeev/Andi had a
good reason not to always separate, and that probably is performance.
IF this impacts overall performance very negatively, then maybe the better
choice is to document it.
I'll try the patch though.
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.316.2.2
diff -u -r1.316.2.2 zend_execute.c
--- zend_execute.c 17 Nov 2002 22:00:32 - 1.316.2.2
+++ zend_execute.c 15 Dec 2002 06:47:03 -
@@ -65,6 +65,7 @@
static void zend_extension_statement_handler(zend_extension *extension, zend_op_array
*op_array TSRMLS_DC);
static void zend_extension_fcall_begin_handler(zend_extension *extension,
zend_op_array *op_array TSRMLS_DC);
static void zend_extension_fcall_end_handler(zend_extension *extension, zend_op_array
*op_array TSRMLS_DC);
+static int _zval_array_disref(zval **ppz);
#define RETURN_VALUE_USED(opline) (!((opline)-result.u.EA.type EXT_TYPE_UNUSED))
@@ -1816,6 +1817,7 @@
} else if (PZVAL_IS_REF(*param)) {
zend_assign_to_variable_reference(NULL, get_zval_ptr_ptr(EX(opline)-result, EX(Ts),
BP_VAR_W), param, NULL TSRMLS_CC);
} else {
+ _zval_array_disref(param);
zend_assign_to_variable(NULL,
EX(opline)-result, NULL, *param, IS_VAR, EX(Ts) TSRMLS_CC);
}
}
@@ -2480,4 +2482,59 @@
}
}
zend_error(E_ERROR, Arrived at end of main loop which shouldn't happen);
+}
+
+static int _zval_ref_check(zval **p, void *flag)
+{
+ if ((*p)-is_ref) {
+ *(int *)flag = 1;
+ }
+ _zval_array_disref(p);
+ return ZEND_HASH_APPLY_KEEP;
+}
+
+static void zval_dis_ref(zval **p)
+{
+ if ((*p)-is_ref) {
+ zval *newzv;
+ ALLOC_ZVAL(newzv);
+ *newzv = **p;
+ zval_copy_ctor(newzv);
+ newzv-refcount = 1;
+ newzv-is_ref = 0;
+
+ if ((*p)-refcount 1) {
+ zval_dtor((*p));
+ FREE_ZVAL(*p);
+ }
+
+ *p = newzv;
+ } else {
+ ((*p))-refcount++;
+ }
+}
+
+static int _zval_array_disref(zval **ppz)
+{
+ TSRMLS_FETCH();
+ if ((*ppz)-type == IS_ARRAY) {
+ int flag = 0;
+ if ((*ppz)-value.ht == EG(symbol_table)) {
+ return SUCCESS;
+ }
+ zend_hash_apply_with_argument((*ppz)-value.ht, (apply_func_arg_t)
+_zval_ref_check, (void *)flag TSRMLS_CC);
+ if (flag) {
+ zval *newzv, *tmp;
+ ALLOC_ZVAL(newzv);
+ *newzv = **ppz;
+ ALLOC_HASHTABLE(newzv-value.ht);
+ zend_hash_init(newzv-value.ht, 0, NULL, ZVAL_PTR_DTOR, 0);
+ zend_hash_copy(newzv-value.ht, Z_ARRVAL_PP(ppz),
+(copy_ctor_func_t) zval_dis_ref, (void *) tmp, sizeof(zval *));
+ zval_ptr_dtor(ppz);
+ *ppz = newzv;
+ newzv-is_ref = 0;
+ newzv-refcount = 1;
+ }
+ }
+ return SUCCESS;
}
?php
function timediff($ts, $te) {
list($ts_usec, $ts_sec) = explode(' ', $ts);
list($te_usec, $te_sec) = explode(' ', $te);
return ((float)$te_usec - (float)$ts_usec) + (float)( (int)$te_sec -
(int)$ts_sec );
}
function test1( $ary ) {
$ary[32048] = '3';
}
function test2( $ary ) {
$ary[32048] = '3';
}
for ($i=0; $i10; ++$i) {
$ary_org[$i] = str_repeat(\\, rand( 0, 12 )).sprintf(%08x,
rand(-1,0x7fff));
}
for ($i=0; $i10; ++$i) {
$ary_ref[$i] = $ary_ref[$i];
}
$ts = microtime();
$ary = $ary_org;
test1($ary);
$te = microtime();
printf(1: %f\n, timediff($ts, $te));
$ts =
[PHP-DEV] Re: #20993 [Ver]: Element value changes without asking
It would be easy to resolve this problem if we were allowed to break
backwards compatibilities, as long as the results of following script can
be said to be expected.
?php
$foo = array(1, 2, 3);
$bar = array();
$i = count($foo);
while (--$i = 0) {
$bar[$i] = $foo[$i];
}
$foo_ref = $foo;
$bar_ref = $bar;
$foo_copy = $foo;
$bar_copy = $bar;
$foo_copy[1] = '?';
echo 'foo: '; debug_zval_dump($foo);
echo 'foo_ref: '; debug_zval_dump($foo_ref);
echo 'foo_copy: '; debug_zval_dump($foo_copy);
echo 'bar: '; debug_zval_dump($bar);
echo 'bar_ref: '; debug_zval_dump($bar_ref);
echo 'bar_copy: '; debug_zval_dump($bar_copy);
?
Is this a kind of Won't fix thing?
Moriyoshi
[EMAIL PROTECTED] wrote:
ID: 20993
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Variables related
Operating System: Any
PHP Version: 4.0CVS-2002-12-13
New Comment:
Verified with 4.2.3
Previous Comments:
[2002-12-13 12:42:22] [EMAIL PROTECTED]
Verified and added testcase to CVS
[2002-12-13 12:01:33] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
do not.
?php
$array = array(1);
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
?
[2002-12-13 12:00:37] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
did not.
?php
$array = array(1);
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
?
--
Edit this bug report at http://bugs.php.net/?id=20993edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20993 [Ver]: Element value changes without asking
This is a pretty well known issue indeed.
I should have read the archive carefully.
Related reports:
http://bugs.php.net/bug.php?id=6417
http://bugs.php.net/bug.php?id=7412
http://bugs.php.net/bug.php?id=7515
http://bugs.php.net/bug.php?id=15025
Moriyoshi
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
It would be easy to resolve this problem if we were allowed to break
backwards compatibilities, as long as the results of following script can
be said to be expected.
?php
$foo = array(1, 2, 3);
$bar = array();
$i = count($foo);
while (--$i = 0) {
$bar[$i] = $foo[$i];
}
$foo_ref = $foo;
$bar_ref = $bar;
$foo_copy = $foo;
$bar_copy = $bar;
$foo_copy[1] = '?';
echo 'foo: '; debug_zval_dump($foo);
echo 'foo_ref: '; debug_zval_dump($foo_ref);
echo 'foo_copy: '; debug_zval_dump($foo_copy);
echo 'bar: '; debug_zval_dump($bar);
echo 'bar_ref: '; debug_zval_dump($bar_ref);
echo 'bar_copy: '; debug_zval_dump($bar_copy);
?
Is this a kind of Won't fix thing?
Moriyoshi
[EMAIL PROTECTED] wrote:
ID: 20993
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: Variables related
Operating System: Any
PHP Version: 4.0CVS-2002-12-13
New Comment:
Verified with 4.2.3
Previous Comments:
[2002-12-13 12:42:22] [EMAIL PROTECTED]
Verified and added testcase to CVS
[2002-12-13 12:01:33] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
do not.
?php
$array = array(1);
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
?
[2002-12-13 12:00:37] [EMAIL PROTECTED]
I create an array an then a reference to an element of that array.
Then the array is passed to a function (by value!) which changes the
value of the element.
After that, the global array has also another value.
I would expect this behaviour if I passed the array by reference but I
did not.
?php
$array = array(1);
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
?
--
Edit this bug report at http://bugs.php.net/?id=20993edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20993 [Ver]: Element value changes withoutasking
This is a pretty well known issue indeed.
I should have read the archive carefully.
Related reports:
http://bugs.php.net/bug.php?id=6417
http://bugs.php.net/bug.php?id=7412
http://bugs.php.net/bug.php?id=7515
http://bugs.php.net/bug.php?id=15025
I wouldn't like to call it 'well-known'.
Misleading words? What I meant was this turned out to be a pretty well
known issue... hardly had I noticed this problem until I saw this report,
I found several related reports during the investigation. So I regarded it
as a kind of them.
And I don't like the implications of 1 perfectly valid statement, impacting
the scope of an array in a non-documented and plain wrong manner.
Is it okay to always perform separation on all the elements of passed
arrays? If so, the attached patch should work.
IF this can't be fixed short term, we surely could detect the statement and
issue a warning?
AFAIK possible. We'll have to trade off performance against usability.
Moriyoshi
Index: zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.316.2.2
diff -u -r1.316.2.2 zend_execute.c
--- zend_execute.c 17 Nov 2002 22:00:32 - 1.316.2.2
+++ zend_execute.c 14 Dec 2002 07:29:19 -
@@ -65,6 +65,7 @@
static void zend_extension_statement_handler(zend_extension *extension, zend_op_array
*op_array TSRMLS_DC);
static void zend_extension_fcall_begin_handler(zend_extension *extension,
zend_op_array *op_array TSRMLS_DC);
static void zend_extension_fcall_end_handler(zend_extension *extension, zend_op_array
*op_array TSRMLS_DC);
+static int _zval_array_disref(zval **ppz);
#define RETURN_VALUE_USED(opline) (!((opline)-result.u.EA.type EXT_TYPE_UNUSED))
@@ -1816,6 +1817,7 @@
} else if (PZVAL_IS_REF(*param)) {
zend_assign_to_variable_reference(NULL, get_zval_ptr_ptr(EX(opline)-result, EX(Ts),
BP_VAR_W), param, NULL TSRMLS_CC);
} else {
+ _zval_array_disref(param);
zend_assign_to_variable(NULL,
EX(opline)-result, NULL, *param, IS_VAR, EX(Ts) TSRMLS_CC);
}
}
@@ -2480,4 +2482,57 @@
}
}
zend_error(E_ERROR, Arrived at end of main loop which shouldn't happen);
+}
+
+static int _zval_ref_check(zval **p, void *flag)
+{
+ if ((*p)-is_ref) {
+ *(int *)flag = 1;
+ }
+ _zval_array_disref(p);
+ return ZEND_HASH_APPLY_KEEP;
+}
+
+static void zval_dis_ref(zval **p)
+{
+ if ((*p)-is_ref) {
+ zval *newzv;
+ ALLOC_ZVAL(newzv);
+ *newzv = **p;
+ zval_copy_ctor(newzv);
+ newzv-refcount = 1;
+ newzv-is_ref = 0;
+ if ((*p)-refcount = 1) {
+ zval_dtor((*p));
+ FREE_ZVAL(*p);
+ }
+ *p = newzv;
+ } else {
+ ((*p))-refcount++;
+ }
+}
+
+static int _zval_array_disref(zval **ppz)
+{
+ TSRMLS_FETCH();
+ if ((*ppz)-type == IS_ARRAY) {
+ int flag = 0;
+ if ((*ppz)-value.ht == EG(symbol_table)) {
+ return SUCCESS;
+ }
+ zend_hash_apply_with_argument((*ppz)-value.ht, (apply_func_arg_t)
+_zval_ref_check, (void *)flag TSRMLS_CC);
+ if (flag) {
+ zval *newzv, *tmp;
+ ALLOC_ZVAL(newzv);
+ *newzv = **ppz;
+ ALLOC_HASHTABLE(newzv-value.ht);
+ zend_hash_init(newzv-value.ht, 0, NULL, ZVAL_PTR_DTOR, 0);
+ zend_hash_copy(newzv-value.ht, Z_ARRVAL_PP(ppz),
+(copy_ctor_func_t) zval_dis_ref, (void *) tmp, sizeof(zval *));
+ zval_ptr_dtor(ppz);
+ *ppz = newzv;
+ newzv-is_ref = 0;
+ newzv-refcount = 1;
+ }
+ }
+ return SUCCESS;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
Hmm... it's natural that when apache is launched at /, it should read
/php.ini because of the current implementation shown below.
274 #ifdef INI_CHECK_CWD
275 if (strcmp(sapi_module.name, cli)!=0) {
276 if (*php_ini_search_path) {
277 strcat(php_ini_search_path, paths_separator);
278 }
279 strcat(php_ini_search_path, .);
280 }
281 #endif
Moriyoshi
Jani Taskinen [EMAIL PROTECTED] wrote:
But unfortunately neither of these fix the bug.
If there is php.ini in /, it's still used.
--Jani
On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
+1 for applying this patch.
and attached is yet another fix as my suggestion.
(a bit dirty, and not tested enough).
Moriyoshi
Sara Golemon [EMAIL PROTECTED] wrote:
I THINK the patch below will fix critical bug #20887, but it's late and
I've had a long day so I havn't begun to make sure it'll work properly in
any circumstance, could anyone else have a look and try it out?
See my note in Bug #20887 for an explanation of what my theory about the
problem is.
-Pollita
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 06:49:50 -
@@ -298,7 +298,9 @@
char *separator_location =
strrchr(binary_location, DEFAULT_SLASH);
if (separator_location) {
- *(separator_location+1) = 0;
+ separator_location[0] = '\0';
+ } else {
+ binary_location[0] = '\0';
}
if (*php_ini_search_path) {
strcat(php_ini_search_path, paths_separator);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
- For Sale! -
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
You are right. I verified Apache changes the cwd to / unless it's been
launched in single process mode.
And I found results could be different by cases, using DSO or using CGI
executable. When you run your script with CGI executable and php.ini is
also present in that directory, the PHP binary tries to read that one as
mod_cgi tries to chdir to where the script is put.
I'm not sure, but this appears to imply some security issues?
Moriyoshi
Derick Rethans [EMAIL PROTECTED] wrote:
On Thu, 12 Dec 2002, Jani Taskinen wrote:
On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
Hmm... it's natural that when apache is launched at /, it should read
/php.ini because of the current implementation shown below.
274 #ifdef INI_CHECK_CWD
275 if (strcmp(sapi_module.name, cli)!=0) {
276if (*php_ini_search_path) {
277strcat(php_ini_search_path, paths_separator);
278}
279strcat(php_ini_search_path, .);
280 }
281 #endif
Yeah, but I'm not launching it at /..
AFAIK apache always does a chdir('/') when you start it.
Derick
--
-
Derick Rethans http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
At the time CLI was introduced I argued to remove . from php.ini
search path, but that was not accepted because some people
apparently use this feature for having different configurations for
different virtual hosts.
Therefore . was removed only from CLI's php.ini search path.
This feature looks somewhat evil since it enables users to bypass the safe
mode restrictions enforced by the administrator, or am I missing
something?
Anyway, the following patch should make sense for #20887?
Moriyoshi
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 11:22:17 -
@@ -272,7 +272,8 @@
/* Add cwd */
#ifdef INI_CHECK_CWD
- if (strcmp(sapi_module.name, cli)!=0) {
+ if (strcmp(sapi_module.name, cgi)==0
+ || strcmp(sapi_module.name, cgi-fcgi)==0) {
if (*php_ini_search_path) {
strcat(php_ini_search_path, paths_separator);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
Thanks for the pointer. As far as I looked over the thread, which is not
so long as I expected, I don't feel there is that much need for including
CWD in php.ini search path. +1 for removing that feature.
Moriyoshi
Edin Kadribasic [EMAIL PROTECTED] wrote:
No because it was preciselly because of cgi that CWD wasn't removed
from the php.ini search path. Have a look at the following thread:
http://www.zend.com/lists/php-dev/200202/msg01325.html
Edin
- Original Message -
From: Moriyoshi Koizumi [EMAIL PROTECTED]
To: Edin Kadribasic [EMAIL PROTECTED]
Cc: Derick Rethans [EMAIL PROTECTED]; Jani Taskinen
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, December 12, 2002 12:44 PM
Subject: Re: [PHP-DEV] Critical Bug #20887
At the time CLI was introduced I argued to remove . from php.ini
search path, but that was not accepted because some people
apparently use this feature for having different configurations
for
different virtual hosts.
Therefore . was removed only from CLI's php.ini search path.
This feature looks somewhat evil since it enables users to bypass
the safe
mode restrictions enforced by the administrator, or am I missing
something?
Anyway, the following patch should make sense for #20887?
Moriyoshi
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 11:22:17 -
@@ -272,7 +272,8 @@
/* Add cwd */
#ifdef INI_CHECK_CWD
- if (strcmp(sapi_module.name, cli)!=0) {
+ if (strcmp(sapi_module.name, cgi)==0
+ || strcmp(sapi_module.name,
cgi-fcgi)==0) {
if (*php_ini_search_path) {
strcat(php_ini_search_path,
paths_separator);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20887 (Two separate issues)
Hi, The original complaint in bug 20887 was that the CLI version was picking up ini files in the wrong places. The patch I suggested last night does address that problem (albiet not correctly, see below). ??? The original report goes: If /php.ini exists, that one is used no matter what PHPRC env is set or compiled in when starting up apache from a SysV script. Is it a bug in php, or could it be the Mandrake Linux 9.0 system? the system checks the PATH variable to find an executable and run PHP. When php_ini.c runs, it finds a 'binary_location' of php (inaccurate! Our CWD is ~ and ~/php does not exist) Neither my patch nor Moriyoshi's fixes this. My patch would give the accurate location of the binary being executed since it doesn't rely on argv[0]. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20887 (Two separate issues)
Note that the patche is still incomplete because it dismisses many *nix OS out there other than SunOS, Linux, FreeBSD, OpenBSD and NetBSD. Moriyoshi Sara Golemon [EMAIL PROTECTED] wrote: ??? The original report goes: If /php.ini exists, that one is used no matter what PHPRC env is set or compiled in when starting up apache from a SysV script. Is it a bug in php, or could it be the Mandrake Linux 9.0 system? My bad, the fact does remain however, that there is a command line issue. the system checks the PATH variable to find an executable and run PHP. When php_ini.c runs, it finds a 'binary_location' of php (inaccurate! Our CWD is ~ and ~/php does not exist) Neither my patch nor Moriyoshi's fixes this. My patch would give the accurate location of the binary being executed since it doesn't rely on argv[0]. Once again, my bad... When I tested your patch on my system I forgot about the fact that the php found in the path would be my copy of 4.2.3 and would therefore not have your patch! Whoops... :) I retested with sapi/cli/php put into the path and lo-and-behold: open(/usr/local/bin//php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php-cli.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/bin//php.ini, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/local/lib/php.ini, O_RDONLY) = 3 Exactly the right behavior! +1 your patch. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
+1 for applying this patch.
and attached is yet another fix as my suggestion.
(a bit dirty, and not tested enough).
Moriyoshi
Sara Golemon [EMAIL PROTECTED] wrote:
I THINK the patch below will fix critical bug #20887, but it's late and
I've had a long day so I havn't begun to make sure it'll work properly in
any circumstance, could anyone else have a look and try it out?
See my note in Bug #20887 for an explanation of what my theory about the
problem is.
-Pollita
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 06:49:50 -
@@ -298,7 +298,9 @@
char *separator_location =
strrchr(binary_location, DEFAULT_SLASH);
if (separator_location) {
- *(separator_location+1) = 0;
+ separator_location[0] = '\0';
+ } else {
+ binary_location[0] = '\0';
}
if (*php_ini_search_path) {
strcat(php_ini_search_path, paths_separator);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 07:52:04 -
@@ -287,11 +287,21 @@
efree(binary_location);
binary_location = NULL;
}
+#elif defined(__linux__)
+ binary_location = (char *) emalloc(MAXPATHLEN);
+ binary_location = realpath(/proc/self/exe, binary_location);
+#elif defined(__svr4__)
+ binary_location = (char *) emalloc(MAXPATHLEN);
+ binary_location = realpath(/proc/self/object/a.out, binary_location);
+#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+ binary_location = (char *) emalloc(MAXPATHLEN);
+ binary_location = realpath(/proc/curproc/file, binary_location);
#else
+ binary_location = NULL;
if (sapi_module.executable_location) {
- binary_location = estrdup(sapi_module.executable_location);
- } else {
- binary_location = NULL;
+ if (sapi_module.executable_location[0] == DEFAULT_SLASH) {
+ binary_location =
+estrdup(sapi_module.executable_location);
+ }
}
#endif
if (binary_location) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Placebo for bug #20539
Hi, Attached is a patch against the PHP_4_3 branch which appears to fix the bug #20539, while I haven't expected for this to be a cure at all. I guess destruction order of constants and resources have something to do with this issue. Moriyoshi Index: php_cli.c === RCS file: /repository/php4/sapi/cli/php_cli.c,v retrieving revision 1.51.2.1 diff -u -r1.51.2.1 php_cli.c --- php_cli.c 14 Nov 2002 21:09:42 - 1.51.2.1 +++ php_cli.c 11 Dec 2002 03:43:01 - @@ -377,22 +377,19 @@ php_stream_to_zval(s_err, zerr); ic.value = *zin; - zval_copy_ctor(ic.value); - ic.flags = CONST_CS | CONST_PERSISTENT; + ic.flags = CONST_CS; ic.name = zend_strndup(STDIN, 6); ic.name_len = 6; zend_register_constant(ic TSRMLS_CC); oc.value = *zout; - zval_copy_ctor(oc.value); - oc.flags = CONST_CS | CONST_PERSISTENT; + oc.flags = CONST_CS; oc.name = zend_strndup(STDOUT, 7); oc.name_len = 7; zend_register_constant(oc TSRMLS_CC); ec.value = *zerr; - zval_copy_ctor(ec.value); - ec.flags = CONST_CS | CONST_PERSISTENT; + ec.flags = CONST_CS; ec.name = zend_strndup(STDERR, 7); ec.name_len = 7; zend_register_constant(ec TSRMLS_CC); -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for Bug #20681: object lookup with array_search()
Hi,
I'm trying to make a slight change on array_search(), which allows object
lookup with array_search() in ZendEngine2.
I think this feature doesn't break backwards compatiblity.
If there seems no problem, I'll commit the patch and close that PR.
Moriyoshi
Index: ext/standard/array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.206
diff -u -r1.206 array.c
--- ext/standard/array.c3 Dec 2002 15:02:06 - 1.206
+++ ext/standard/array.c4 Dec 2002 07:21:07 -
@@ -1056,12 +1056,12 @@
zend_get_parameters_ex(ZEND_NUM_ARGS(), value, array, strict) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
-
+#ifndef ZEND_ENGINE_2
if (Z_TYPE_PP(value) == IS_OBJECT) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Wrong datatype for first
argument);
RETURN_FALSE;
}
-
+#endif
if (Z_TYPE_PP(array) != IS_ARRAY) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Wrong datatype for second
argument);
RETURN_FALSE;
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #20755 [Opn-Ver]: exif relocation error
--snip If you compile mbstring as static module, you can workaround this error. It's not very good idea to enable it anyway.. I'm wondering why you referred to enabling mbstring as no good idea in this report. I believe the problem has been properly avoided, or am I missing something? For the mbstring authors: You should decide whether or not to allow external usage of these functions (ie. in other extensions) or disable the building of this extension as shared altogether.. What decision? We actually externalise some functions just for that purpose. Perhaps did you mean integration of mbstring into core part? BTW we are now working on a new mbstring API specification so that other extension authors can use the functions with more convenience and in no more doubt about their usage. If we should treat it in a special way, please let us know. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New iconv functions being introduced
Hi, I've implemented some string related functions that make use of iconv(). Following is the list of them. = - _php_iconv_appendl() Converts the given string in the way specified by a conversion descriptor and then appends it with smart_str_appendl(). Note that the string being converted is not expected to be encoded with stateful encodings such as iso-2022-kr. - _php_iconv_appendc() The single character version of _php_iconv_appendl(). - _php_iconv_strlen() Character-mapping aware version of strlen(). Returns the actual count of characters in a string, not the length of the string in bytes. See also the description of mb_strlen(). - _php_iconv_substr() Character-mapping aware version of substr(). Offsets should be expressed as the nunber of the leading characters counted from the beginning. See also the description of mb_substr. - _php_iconv_strpos() Character-mapping aware version of strpos(). Returns the position of the first occurrence of the needle that is expressed in the manner of character count described so far. See also the description of mb_strpos(). - _php_iconv_mime_encode() Composes and returns a mime header from the given field name and the value. The encoding scheme is defined in rfc2047. - _php_iconv_mime_decode() Decodes the mime header and returns the result. This function may fail when the conversion is being performed between two incompatible character-mappings. = Userland functions: proto int iconv_strlen(string str [, string charset]); proto string iconv_substr(string str, int offset, int length [, string charset]); proto string iconv_strpos(string haystack, string needle, int offset [, string charset]); proto string iconv_strrpos(string haystack, string needle [, string charset]); proto string iconv_mime_encode(string field_name, string field_value, string scheme, string out_charset [, string in_charset, int line_len, string lfchars]); proto string iconv_mime_decode(string encoded_string [, string charset]); = If interested, you can fetch the patch at http://www.voltex.jp/patches/iconv_functions-patch.diff.gz But I'm not sure if these are really needed while mbstring offers the same facility. So it would rather depend on the result of discussion whether I commit this patch or not :) Your comments will be greatly appreciated. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20755 [Opn-Ver]: exif relocation error)
Hi, Jani Taskinen [EMAIL PROTECTED] wrote: On Tue, 3 Dec 2002, Moriyoshi Koizumi wrote: --snip If you compile mbstring as static module, you can workaround this error. It's not very good idea to enable it anyway.. I'm wondering why you referred to enabling mbstring as no good idea in this report. I believe the problem has been properly avoided, or am I missing something? Maybe I just assumed something, but I think this person really doesn't even need it. :) That's why I also noted about enabling only extensions that he actually needs. The biggest concern about mbstring for me is that it changes some core functions behaviour. I haven't followed the development of mbstring closely so I might be wrong here..just that one major bug caused by that duplication of code (for post vars parsing) gives me creeps. :) As long as it's separate from core PHP, I will never suggest anybody to use it. I could understand the reason of your severe glance at the module, but please, please stop blaming mbstring for the reported bugs which you might suppose don't appear to be fixed in a moment :P Most of them are totally irrelevant. BTW that most infamous bug was caused by a carelessness rather than the duplication of codes. For the mbstring authors: You should decide whether or not to allow external usage of these functions (ie. in other extensions) or disable the building of this extension as shared altogether.. What decision? We actually externalise some functions just for that purpose. Perhaps did you mean integration of mbstring into core part? Yes. But mbstring is not the only extension having the same problem when compiled as shared. At least iconv, openssl, pcre and gd also have some external parts used outside them. e.g. All the extensions and core parts using those externalized functions in mbstring must now put these around the parts using those: #ifndef COMPILE_DL_MBSTRING #endif This is done in some places, but not everywhere, like shown by the bug report. The same problem is also with PCRE and GD extensions. One solution would be to make at least PCRE and MBstring always static, ie. disallow building them as shared. Or move them under ext/standard.. With openssl and iconv it's a bit different, the same libraries are required by other extensions. This problem could be solved by linking the core PHP always with those, even when compiling openssl or iconv as shared extensions. I see the issue around the shared extensions too. We definitely need more clever dynamic loading mechanism as Yasuo mentioned. I don't think mbstring needs to be built static as long as it exists as an extension. BTW we are now working on a new mbstring API specification so that other extension authors can use the functions with more convenience and in no more doubt about their usage. If we should treat it in a special way, please let us know. Yeah, keep it simple. :) Okay, it's not always prone to be complicated :) Moriyoshi --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 27 Nov 2002, Sara Pollita Golemon wrote: User complains that maximum length of a line used by fscanf is too short (he has lines 1600 chars). Looking at file.h I agree (it's only 512). The user requested two options: 1) Add an optional length field. No way to do that without breaking parameter list. :( We can't really do that, users will get pissed :) 2) Increase to a larger arbitrary number. This simply has the problem that it may prove too short eventually as well. Yeah, IMO it doesn't solve anything. Plus I came up with a third option: 3) Create an .ini entry to specify the maximum length used. I think this has the best overall return on it. I don't like us adding a new ini entry for this, I think we should try another option: 4) Make sure we can use fscanf on a dynamically sized buffer. This will definitely the hardest solution, but also the most beautiful one. I like this fourth option, because the internal scanf function will anyway need reimplementation since it's not binary safe. Moriyoshi Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
err. it didn't need a reimplementation, i fixed it, it works fine in cvs. Then, ?php $buf = 123 456 \0 567 sscanf($buf, %d%d%s%d, $a, $b, $c, $d); var_dump($a, $b, $c, $d); ? How about this? The result was the same as for fscanf. Moriyoshi -Sterling Moriyoshi Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20460 (Feature Request)
Sterling Hughes [EMAIL PROTECTED] wrote: err. it didn't need a reimplementation, i fixed it, it works fine in cvs. Then, ?php $buf = 123 456 \0 567 sscanf($buf, %d%d%s%d, $a, $b, $c, $d); var_dump($a, $b, $c, $d); ? How about this? The result was the same as for fscanf. Yes, but it didn't need a reimplementation as far as using arbitrary buffer sizes. Right, I just missed a big point about the scanf behaviour :) Moriyoshi -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: V API Ä
what's this? :)
Did you get interested?
Hmm, it went on like following...
p.s. please keep quiet on this for now though I guess you'll find a lot to
say about :)
Moriyoshi
- translated message begins here -
Hi,
I'm now planning on a new mbstring API as referencing to HEAD on
cvs.php.net and that on sourceforge.jp.
I hope this helps us determine the final API spec so that we can
integrate those two different code bases, though I doesn't mean a faster
development without consensus should come first.
The most significant change you may find is that error number values are
no longer stored in a thread-local structure (tsrm resource). IMO this
could improve code readabilities while it would also make debugging harder.
Besides, I'm trying to add to each API function an argument that is a
pointer to the error reporting function specified by the caller.
The purpose is that we can choose the way in which the error messages
are shown since we cannot invoke a kind of php_error_docref() from
everywhere, as I mentioned.
Your comments will be greatly appreciated.
Regards,
Moriyoshi
- translated message ends -
/*
+--+
| PHP Version 4|
+--+
| Copyright (c) 1997-2002 The PHP Group|
+--+
| This source file is subject to version 2.02 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is|
| available at through the world-wide-web at |
| http://www.php.net/license/2_02.txt. |
| If you did not receive a copy of the PHP license and are unable to |
| obtain it through the world-wide-web, please send a note to |
| [EMAIL PROTECTED] so we can mail you a copy immediately. |
+--+
| Author: Moriyoshi Koizumi [EMAIL PROTECTED]|
+--+
*/
/* $Id$ */
#ifndef _PHP_MB_API_H
#define _PHP_MB_API_H
#include php.h
#if HAVE_MBSTRING
/* {{{ includes */
#ifdef USE_MBSTRING1
# include mbfilter.h
#endif /* USE_MBSTRING1 */
/* }}} */
/* {{{ type definitions */
/* {{{ typedef enum php_mb_err_t */
typedef enum _php_mb_err_t {
PHP_MB_FAILURE = -1,
PHP_MB_SUCCESS = 0,
PHP_MB_ERR_NO_MEMORY,
PHP_MB_ERR_NULL_POINTER,
PHP_MB_ERR_BUFFER_OVER_FLOW,
PHP_MB_ERR_UNSUPPORTED_ENCODING,
PHP_MB_ERR_UNSUPPORTED_LANGUAGE,
PHP_MB_ERR_UNSUPPORTED_CONVERT,
PHP_MB_ERR_UNSUPPORTED_IDENTIFY,
PHP_MB_ERR_ILLEGAL_ARGUMENT,
PHP_MB_ERR_MISSING_PROPERTY,
PHP_MB_ERR_INDEX_OUT_OF_BOUNDS,
PHP_MB_ERR_ENCODING_DETECT_FAILURE,
PHP_MB_ERR_NOT_FOUND,
PHP_MB_ERR_NOT_IMPLEMENTED
} php_mb_err_t;
/* }}} */
#ifdef USE_MBSTRING1 /* compatibility stuff */
typedef mbfl_no_encoding php_mb_encid;
typedef mbfl_encoding php_mb_enc;
typedef mbfl_language php_mb_lang;
#define php_mb_langid_invalid mbfl_no_language_invalid
#define php_mb_langid_neutral mbfl_no_language_neutral
#define php_mb_langid_jajp mbfl_no_language_japanese
#define php_mb_langid_enuk mbfl_no_language_english
#define php_mb_langid_enus mbfl_no_language_english
#define php_mb_langid_kokr mbfl_no_language_korean
#define php_mb_langid_zhcn mbfl_no_language_simplied_chinese
#define php_mb_langid_zhtw mbfl_no_language_traditional_chinese
#define php_mb_encid_invalidmbfl_no_encoding_invalid
#define php_mb_encid_pass mbfl_no_encoding_pass
#define php_mb_encid_auto mbfl_no_encoding_auto
#define php_mb_encid_wchar mbfl_no_encoding_wchar
#define php_mb_encid_byte2bembfl_no_encoding_byte2be
#define php_mb_encid_byte2lembfl_no_encoding_byte2le
#define php_mb_encid_byte4bembfl_no_encoding_byte4be
#define php_mb_encid_byte4lembfl_no_encoding_byte4le
#define php_mb_encid_base64 mbfl_no_encoding_base64
#define php_mb_encid_uuencode mbfl_no_encoding_uuencode
#define php_mb_encid_qprint mbfl_no_encoding_qprint
#define php_mb_encid_7bit mbfl_no_encoding_7bit
#define php_mb_encid_8bit mbfl_no_encoding_8bit
#define php_mb_encid_ucs4 mbfl_no_encoding_ucs4
#define php_mb_encid_ucs4be mbfl_no_encoding_ucs4be
#define php_mb_encid_ucs4le mbfl_no_encoding_ucs4le
#define php_mb_encid_ucs2 mbfl_no_encoding_ucs2
#define php_mb_encid_ucs2be mbfl_no_encoding_ucs2be
#define php_mb_encid_ucs2le mbfl_no_encoding_ucs2le
#define php_mb_encid_utf32 mbfl_no_encoding_utf32
#define php_mb_encid_utf32bembfl_no_encoding_utf32be
#define php_mb_encid_utf32le
Re: [PHP-DEV] php bugs (Chinese word display problem)-help
Hi, Samuel As far as I know, CP936 characters which is commonly used in MS products are basically not allowed to use in PHP scripts. You have to use UTF-8 encoding in such case. Anyway, this is wrong list for this kind of question, so better ask this at [EMAIL PROTECTED] Regards, Moriyoshi [EMAIL PROTECTED] wrote: Hi, everyone: I am a Chinese, I am a programmer. I encounter a problem about php. Attachment is 1.php, when i open this file (this file is saved at linux server, apache and php 4.2.3 are installed on this server) in Internet Explorer, error displays: Parse error: parse error, expecting `','' or `';'' in /usr/3give/test/1.php on line 5 (If your computer is windows 2000, and Simplify Chinese and Traditional chinese language are installed) you will read the Chinese word. I found that if the hex code for Chinese word ends with '5C', then the error will exist. Anymore, if I input a Chinese word which hex code ends with '5C' in the database field, then the display result will add a suffix '\', for example, if i input Î , it will display Î \ at the browser (Internet explorer). I don't know why this problem exist, can you solve this problem for us? Contact me by: [EMAIL PROTECTED]; (86)755-27232311-samuel Best regards Thanks. Samuel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I'm a bit late here, with an example which probably sounds interesting;
that is a computer language which was actually developed in Japan as a
product mainly for educational use, which enables you to program in nearly
complete Japanese syntax. I thnik it's undoubtfully great, but I have
never seen it become popular by now.
I guess part of the reason is that most of the folks there take it for
granted that they have to be familiar with English as well as the
behaviour of the computer.
Anyway, I'm +0 for the localization of messages.
Moriyoshi
Daniel Lorch [EMAIL PROTECTED] wrote:
hi,
What you're missing is that currently to program PHP, you need a reasonable
understanding of english. [..]
I agree with Sterlin. I mean, what's next? Also localize language constructs?
?php
während (EUR i=0; EUR i5; ++EUR i) {
ausgabe(Hallo);
wenn (EUR i % 5) {
[..]
}
}
Uah.. terrible.
-daniel
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
I almost agree with you, but please note that error message translation is not always the simple thing because the word order varies by language. For example, Warning: Argument %1 to array_diff() is not an array in - on line %2 the above message should be translated into Japanese romaji script as following: Keikoku: %2 gyou me - array_diff() no %1 banme no hikisu ga hairetsu de ha arimasen. %2 gyou me means line %2, and %1 banme no hikisu means Argument %1, where gyou me and banme are suffixes that indicate the order of subjects. This trivial example implies that sprintf() cannot be used for error message reporting at all in this case, which may result in a mess. Regards, Moriyoshi Alexander Wagner [EMAIL PROTECTED] wrote: On Monday 25 November 2002 21:55, Sascha Schumann wrote: Whereas assuming that PHP users are too stupid to understand english is not at all arrogant? :) Wrong, Sterling. Beginning PHP users might neither have formal education in computer science _nor_ foreign languages. Perfectly true. Some people just lack education, or are too young or too old. The average newbie: - uses M$ Windows - with a WAMP-all-in-one package, or, failing to know such things exist, uploads to some free webspace for testing - thinks PHP-Nuke is the high art of programming - doesn't even know that there is such a thing as a manual I happen to help these people rather often... there are a lot of them. If you just put a translation online... believe me, they're never going to find it. The people who will find it probably won't need it. If you want these people to find this translation, you'd have to put the url into every error-message. And provide a way to change the root-url, so it can be downloaded The strength of PHP is that, for some reason, it's so easy to use that even people with no programming background at all use it, very often with a complete lack of skill and a minimum of effort. From the perspective of newbies, translated error-messages are definately the right thing (tm). If you want them to find the translation, you have to present it in a way that they cannot possibly miss it. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
Ah my bad. It's totally beyond my expectation... Then how about RTL languages? They need some bidi processing. Moriyoshi Sascha Schumann [EMAIL PROTECTED] wrote: sprintf handles these cases easily. Warning: Argument %1 to array_diff() is not an array in - on line %2 sprintf(argument %1$s.. line %2$s, arg, line); the above message should be translated into Japanese romaji script as following: Keikoku: %2 gyou me - array_diff() no %1 banme no hikisu ga hairetsu de ha arimasen. sprintf(%2$s gyou me.. no %1$s, arg, line); - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error (fwd)
I have no idea on this issue now though I guess this is a problem of ISP that I'm using. Sorry for the inconvenience. Moriyoshi Sascha Schumann [EMAIL PROTECTED] wrote: Looks like some program in the chain erroneously appended @vckyb3.nw.wakwak.com. - Sascha -- Forwarded message -- Date: Mon, 25 Nov 2002 23:31:08 +0100 (CET) From: Sascha Schumann [EMAIL PROTECTED] To: Moriyoshi Koizumi [EMAIL PROTECTED] Cc: Alexander Wagner [EMAIL PROTECTED], Sterling Hughes [EMAIL PROTECTED], Ilia A. [EMAIL PROTECTED], [EMAIL PROTECTED], @vckyb3.nw.wakwak.com, 'PHP.Developers.Mailing.List'@vckyb3.nw.wakwak.com, [EMAIL PROTECTED]@at.wakwak.com Subject: Re: [PHP-DEV] [PATCH] Redirect on Error sprintf handles these cases easily. Warning: Argument %1 to array_diff() is not an array in - on line %2 sprintf(argument %1$s.. line %2$s, arg, line); the above message should be translated into Japanese romaji script as following: Keikoku: %2 gyou me - array_diff() no %1 banme no hikisu ga hairetsu de ha arimasen. sprintf(%2$s gyou me.. no %1$s, arg, line); - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: .....
Sorry, I failed to post the previous mail to the right list. Just ignore it. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for range()
Thanks for the review.
Also I'll add a test for this function.
BTW how about renaming it to array_range() and adding an alias for BC?
Moriyoshi
Jon Parise [EMAIL PROTECTED] wrote:
On Sat, Nov 23, 2002 at 03:37:29PM +0900, Moriyoshi Koizumi wrote:
I've just found range() behaves unexpectedly in some special cases.
For instance, please try the following script.
?php
echo count(range('a', 'z', 12));
?
will give 45 while it should return an array that consists of 3 elements.
That is because the counting may exceed the upper limit of positive char
value during the loop.
The attached patch is a fix for this issue. I'll commit this if there are
no objections.
No objections (although I haven't actually applied and run your
patch). Thanks for investigating this. I should have tested a wider
set of step values in my original tests.
--
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c
Hmm, since nothing is mentioned about the rule of character sequence
(Bgeneration in the manual, I don't think it's so necessary. IMO this new
(Bfeature introduced in 4.1.0 should not be included in the first place
(Bbecause it broke backwards compatibilities pretty much as one of the user
(Bcontributed notes says and its behaviour is also as unexpectable as the
(Bnumber of charset - encoding mappings out there.
(B
(BMoriyoshi
(B
(BJon Parise [EMAIL PROTECTED] wrote:
(B
(B On Sat, Nov 23, 2002 at 08:47:45PM +0900, Moriyoshi Koizumi wrote:
(B
(B Just a notice:
(B
(B The third optional parameter is not suggested in the branch.
(B Therefore I won't try to merge this patch to PHP_4_3, but due to this
(B decision the behaviour of the function slightly differs one another in the
(B cases like range("A", "$B%H(B");
(B
(B Please add a note to this effect in the manual. There are already
(B some behavior-related notes at the bottom of the range() documentation.
(B
(B --
(B Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
(B
(B --
(B PHP Development Mailing List http://www.php.net/
(B To unsubscribe, visit: http://www.php.net/unsub.php
(B
(B
(B
(B--
(BPHP Development Mailing List http://www.php.net/
(BTo unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c
I think the step option which you added is quite useful in every case. Why didn't you merge into the branch? there seems no BC problem about it. Moriyoshi On Sun, Nov 24, 2002 at 03:28:45AM +0900, Moriyoshi Koizumi wrote: Hmm, since nothing is mentioned about the rule of character sequence generation in the manual, I don't think it's so necessary. IMO this new feature introduced in 4.1.0 should not be included in the first place because it broke backwards compatibilities pretty much as one of the user contributed notes says and its behaviour is also as unexpectable as the number of charset - encoding mappings out there. Yes, I can see that causing problems. I think it's necessary to leave the capability to generate character sequences in there now, though, for all sorts of backwards-compatibility reasons. My change to range() (the addition of the step parameter) was primarily inspired by Python's range() function, described here: http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-47 The Python version does not handle characters, which (as we both agree) is the better implementation. -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for gd.c
Hi,
This tiny patch prevents the warnings when applying imagecolordeallocate()
on true colour values. I suppose this new behaviour would be more
consistent because we can use imagecolorallocate() with true colour images.
Then what do you guys think about this issue?
Moriyoshi
Index: ext/gd/gd.c
===
RCS file: /repository/php4/ext/gd/gd.c,v
retrieving revision 1.223
diff -u -r1.223 gd.c
--- ext/gd/gd.c 14 Nov 2002 15:09:53 - 1.223
+++ ext/gd/gd.c 22 Nov 2002 20:59:19 -
@@ -1874,6 +1874,11 @@
gdImageColorDeallocate(im, col);
RETURN_TRUE;
} else {
+#if HAVE_LIBGD20
+ if (gdImageTrueColor(im)) {
+ RETURN_TRUE;
+ }
+#endif
php_error_docref(NULL TSRMLS_CC, E_WARNING, Color index %d out of
range, col);
RETURN_FALSE;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for gd.c
Thanks! Moriyoshi Rasmus Lerdorf [EMAIL PROTECTED] wrote: I have committed this, sort of anyway. I moved the check up as there is really no reason to go through and even try to do the deallocate on a truecolour image. -Rasmus On Sat, 23 Nov 2002, Moriyoshi Koizumi wrote: Hi, This tiny patch prevents the warnings when applying imagecolordeallocate() on true colour values. I suppose this new behaviour would be more consistent because we can use imagecolorallocate() with true colour images. Then what do you guys think about this issue? Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for range()
Hi,
I've just found range() behaves unexpectedly in some special cases.
For instance, please try the following script.
?php
echo count(range('a', 'z', 12));
?
will give 45 while it should return an array that consists of 3 elements.
That is because the counting may exceed the upper limit of positive char
value during the loop.
The attached patch is a fix for this issue. I'll commit this if there are
no objections.
Moriyoshi
Index: ext/standard/array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.201
diff -u -r1.201 array.c
--- ext/standard/array.c15 Nov 2002 02:16:41 - 1.201
+++ ext/standard/array.c23 Nov 2002 06:20:16 -
@@ -1435,19 +1435,29 @@
/* If the range is given as strings, generate an array of characters. */
if (Z_TYPE_P(zlow) == IS_STRING Z_TYPE_P(zhigh) == IS_STRING) {
- char *low, *high;
+ unsigned char *low, *high;
convert_to_string_ex(zlow);
convert_to_string_ex(zhigh);
- low = Z_STRVAL_P(zlow);
- high = Z_STRVAL_P(zhigh);
+ low = (unsigned char *)Z_STRVAL_P(zlow);
+ high = (unsigned char *)Z_STRVAL_P(zhigh);
if (*low *high) { /* Negative steps */
- for (; *low = *high; (*low) -= step) {
+ if (*low - *high step || step 0) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, step
+exceeds the specified range);
+ zval_dtor(return_value);
+ RETURN_FALSE;
+ }
+ for (; *low = *high; (*low) -= (unsigned int)step) {
add_next_index_stringl(return_value, low, 1, 1);
}
} else {/* Positive steps */
- for (; *low = *high; (*low) += step) {
+ if (*high - *low step || step 0) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, step
+exceeds the specified range);
+ zval_dtor(return_value);
+ RETURN_FALSE;
+ }
+ for (; *low = *high; (*low) += (unsigned int)step) {
add_next_index_stringl(return_value, low, 1, 1);
}
}
@@ -1460,10 +1470,20 @@
high = Z_LVAL_P(zhigh);
if (low high) { /* Negative steps */
+ if (low - high step || step 0) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, step
+exceeds the specified range);
+ zval_dtor(return_value);
+ RETURN_FALSE;
+ }
for (; low = high; low -= step) {
add_next_index_long(return_value, low);
}
} else {/* Positive steps */
+ if (high - low step || step 0) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, step
+exceeds the specified range);
+ zval_dtor(return_value);
+ RETURN_FALSE;
+ }
for (; low = high; low += step) {
add_next_index_long(return_value, low);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch
Hi,
Excuse me for the late reply.
I reviewed the patch and adjusted the style to the coding standards.
Attached is the revised version diff'ed against HEAD. Please verify it.
And please be sure to check out CODING_STANDARDS included in the source
package before submitting the patch from now on.
BTW, your code doesn't seem to handle the string that might result in a
string longer than 256 bytes. IMO erealloc() is lacking somewhere. As for
the other part, I see no obvious problems.
Moriyoshi
Adrian Gartland [EMAIL PROTECTED] wrote:
New patch applied against the current php4-latest.tar.gz,
same location:
http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch
On 11 Nov 02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
Could you make a patch diff'ed against the latest version of html.c in HEAD
branch? determine_charset() issue which you pointed out seems to have been
fixed already.
Moriyoshi
Adrian Gartland [EMAIL PROTECTED] wrote:
http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch
On 11 Nov 02, Jan Schneider [EMAIL PROTECTED] wrote:
Zitat von Adrian Gartland [EMAIL PROTECTED]:
Attached is a patch which allows iso-2022-jp (jis) encoded text to be
passed through htmlspecialchars when the character set is
set to ISO-2022-JP.
It should also fix a tiny bug I found in determine_charset
code where len hadn't been set and then doing its
charset map walk.
Your attachment didn't go through the mailing list filters. Please post a
link where the patch can be downloaded.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
Adrian Gartland - Senior Systems Engineer - TV Portal Team
Oregan Networks UK Ltd Tel: +44 (0) 20 8846 0990
The White Building, 52-54 Glentham RoadFax: +44 (0) 20 8646 0999
Barnes, London. SW13 9JJ, United Kingdom WWW: http://www.oregan.net/
--- html.c Mon Nov 18 04:11:27 2002
+++ html.c.next Tue Nov 19 05:51:43 2002
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: html.c,v 1.65 2002/11/16 08:30:31 sebastian Exp $ */
+/* $Id: html.c,v 1.63 2002/11/11 13:31:08 moriyoshi Exp $ */
#include php.h
#if PHP_WIN32
@@ -43,7 +43,7 @@
#endif
enum entity_charset { cs_terminator, cs_8859_1, cs_cp1252,
- cs_8859_15, cs_utf_8, cs_big5, cs_gb2312,
+ cs_8859_15, cs_2022_jp, cs_utf_8, cs_big5,
+cs_gb2312,
cs_big5hkscs, cs_sjis, cs_eucjp};
typedef const char *entity_table_t;
@@ -288,6 +288,7 @@
} charset_map[] = {
{ ISO-8859-1, cs_8859_1 },
{ ISO8859-1, cs_8859_1 },
+ { ISO-2022-JP,cs_2022_jp },
{ ISO-8859-15,cs_8859_15 },
{ ISO8859-15, cs_8859_15 },
{ utf-8, cs_utf_8 },
@@ -728,8 +729,138 @@
}
/* }}} */
+/* {{{ next_iso2022_segment
+ * updates whatever psIn is pointing to the end of the multi-byte run
+ * esc$bxesc(by ; psIn =
+ */
+static const char *next_iso2022_segment(const unsigned char **psIn, int iInLen, const
+char *pcEscapeSafeEnd)
+{
+ const char *sIn = *psIn;
+ const char *pcNextEsc;
+ static const char cEsc = 033;
+ int iSegmentLength;
+ int iRemaining = iInLen;
+
+ pcNextEsc = sIn;
+ if (sIn pcEscapeSafeEnd) {
+ /* Buffer overrun if we try and spot the escape chars */
+ *psIn = sIn + iInLen;
+ return sIn;
+ } else {
+ while(1) {
+ pcNextEsc++; /* step past the current escape */
+
+ /* search for the closing escape sequence */
+ while (cEsc != *pcNextEsc iRemaining) {
+ iRemaining--;
+ pcNextEsc++;
+ }
+
+ if (cEsc != *pcNextEsc) {
+ pcNextEsc = NULL;
+ }
+
+
+ if (NULL == pcNextEsc || pcNextEsc pcEscapeSafeEnd) {
+ *psIn = sIn + iInLen;
+ return sIn;
+ } else {
+ if ('(' == pcNextEsc[1]) {
+ /*End of multi-byte run
Re: [PHP-DEV] mime_magic segfaults
Thanks, it works.
Attacthed is a slightly modified version of Ilia's patch in consideration
of win32 build.
If there are no objections, I'll commit it.
Moriyoshi
Ilia A. [EMAIL PROTECTED] wrote:
Could you try the attached patch and see if it fixes the problem.
Ilia
On November 14, 2002 03:10 pm, Moriyoshi Koizumi wrote:
Hi,
I found a bug in mime_magic. If the module fails to read the magic file
specified by mime_magic.magicfile during the module initialisation, it
tries to put an error, and then segfaults.
Here's the backtrace.
#0 0x0813402b in sapi_send_headers (tsrm_ls=0x8277f68)
at /home/koizumi/src/php.net/HEAD/php4/main/SAPI.c:673
#1 0x080e5ce2 in php_header ()
at /home/koizumi/src/php.net/HEAD/php4/ext/standard/head.c:62
#2 0x08171433 in sapi_cli_log_message (
message=0x82a5c74 PHP Warning: mime_magic: can't read magic file
.ext/mime _magic/tests/magic.test.1 in Unknown on line 0)
at /home/koizumi/src/php.net/HEAD/php4/sapi/cli/php_cli.c:174
#3 0x0812d639 in php_log_err (
log_message=0x82a5c74 PHP Warning: mime_magic: can't read magic file
.ext/ mime_magic/tests/magic.test.1 in Unknown on line 0,
tsrm_ls=0x8277f68) at /home/koizumi/src/php.net/HEAD/php4/main/main.c:360
#4 0x0812dc9a in php_error_cb (type=2, error_filename=0x8228eab Unknown,
error_lineno=0, format=0x81fcb00 mime_magic: can't read magic file
%s, args=0xbfffd7b8) at
/home/koizumi/src/php.net/HEAD/php4/main/main.c:600 #5 0x081581d9 in
zend_error (type=2,
format=0x81fcb00 mime_magic: can't read magic file %s)
at /home/koizumi/src/php.net/HEAD/php4/Zend/zend.c:711
#6 0x080b2206 in apprentice ()
at /home/koizumi/src/php.net/HEAD/php4/ext/mime_magic/mime_magic.c:348
#7 0x080b1f4e in zm_startup_mime_magic (type=1, module_number=9,
tsrm_ls=0x8277f68)
at /home/koizumi/src/php.net/HEAD/php4/ext/mime_magic/mime_magic.c:266
#8 0x0815a053 in zend_startup_module (module=0x82577a0)
at /home/koizumi/src/php.net/HEAD/php4/Zend/zend_API.c:1008
#9 0x0812ec2b in php_startup_extensions (ptr=0x82621a0, count=15)
at /home/koizumi/src/php.net/HEAD/php4/main/main.c:974
#10 0x08172732 in php_startup_internal_extensions ()
at main/internal_functions_cli.c:79
#11 0x0812f090 in php_module_startup (sf=0x8261f60, additional_modules=0x0,
num_additional_modules=0)
at /home/koizumi/src/php.net/HEAD/php4/main/main.c:1138
#12 0x08171955 in main (argc=1, argv=0xba94)
at /home/koizumi/src/php.net/HEAD/php4/sapi/cli/php_cli.c:446
#13 0x40318507 in __libc_start_main (main=0x81717e8 main, argc=1,
ubp_av=0xba94, init=0x80671f8 _init, fini=0x8172770 _fini,
rtld_fini=0x4000dc14 _dl_fini, stack_end=0xba8c)
at ../sysdeps/generic/libc-start.c:129
IMO php_error() should not be used in PHP_MINIT_FUNCTION. Any fix else?
Moriyoshi
Index: mime_magic.c
===
RCS file: /repository/php4/ext/mime_magic/mime_magic.c,v
retrieving revision 1.14
diff -u -r1.14 mime_magic.c
--- mime_magic.c15 Nov 2002 01:45:23 - 1.14
+++ mime_magic.c15 Nov 2002 11:51:31 -
@@ -304,6 +304,11 @@
return;
}
+ if ((int) conf-magic == -1) {
+php_error(E_ERROR, MODNAME could not be initialized, magic file %s
+is not avaliable, conf-magicfile);
+ RETURN_FALSE;
+ }
+
if(!conf-magic) {
php_error(E_WARNING, MODNAME not initialized);
RETURN_FALSE;
@@ -343,10 +348,9 @@
magic_server_config_rec *conf = mime_global;
fname = conf-magicfile; /* todo cwd? */
-f = fopen(fname, r);
+f = fopen(fname, rt);
if (f == NULL) {
- php_error(E_WARNING,
-MODNAME : can't read magic file %s, fname);
+ (int) conf-magic = -1;
return -1;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for bug #19566
Hmm, your patch is a bit less sexy because of replaced white spaces.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
The following patch for bug #19566 is open but should make it into 4.3.
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 15 Nov 2002 10:49:12 -
@@ -722,9 +722,9 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +733,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for bug #19566
No, it's not committed yet.
Both Marcus and me doesn't have access to Zend module.
Moriyoshi
Andi Gutmans [EMAIL PROTECTED] wrote:
Wasn't this commited a while ago?
Andi
At 11:58 AM 11/15/2002 +0100, Marcus Börger wrote:
The following patch for bug #19566 is open but should make it into 4.3.
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 15 Nov 2002 10:49:12 -
@@ -722,9 +722,9 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +733,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for bug #19566
Thanks.
Could you merge the patch into ZE1 also?
Moriyoshi
Andi Gutmans [EMAIL PROTECTED] wrote:
Commited.
Andi
At 11:22 PM 11/15/2002 +0900, Moriyoshi Koizumi wrote:
No, it's not committed yet.
Both Marcus and me doesn't have access to Zend module.
Moriyoshi
Andi Gutmans [EMAIL PROTECTED] wrote:
Wasn't this commited a while ago?
Andi
At 11:58 AM 11/15/2002 +0100, Marcus Börger wrote:
The following patch for bug #19566 is open but should make it into 4.3.
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 15 Nov 2002 10:49:12 -
@@ -722,9 +722,9 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +733,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mime_magic segfaults
Hi, I found a bug in mime_magic. If the module fails to read the magic file specified by mime_magic.magicfile during the module initialisation, it tries to put an error, and then segfaults. Here's the backtrace. #0 0x0813402b in sapi_send_headers (tsrm_ls=0x8277f68) at /home/koizumi/src/php.net/HEAD/php4/main/SAPI.c:673 #1 0x080e5ce2 in php_header () at /home/koizumi/src/php.net/HEAD/php4/ext/standard/head.c:62 #2 0x08171433 in sapi_cli_log_message ( message=0x82a5c74 PHP Warning: mime_magic: can't read magic file .ext/mime _magic/tests/magic.test.1 in Unknown on line 0) at /home/koizumi/src/php.net/HEAD/php4/sapi/cli/php_cli.c:174 #3 0x0812d639 in php_log_err ( log_message=0x82a5c74 PHP Warning: mime_magic: can't read magic file .ext/ mime_magic/tests/magic.test.1 in Unknown on line 0, tsrm_ls=0x8277f68) at /home/koizumi/src/php.net/HEAD/php4/main/main.c:360 #4 0x0812dc9a in php_error_cb (type=2, error_filename=0x8228eab Unknown, error_lineno=0, format=0x81fcb00 mime_magic: can't read magic file %s, args=0xbfffd7b8) at /home/koizumi/src/php.net/HEAD/php4/main/main.c:600 #5 0x081581d9 in zend_error (type=2, format=0x81fcb00 mime_magic: can't read magic file %s) at /home/koizumi/src/php.net/HEAD/php4/Zend/zend.c:711 #6 0x080b2206 in apprentice () at /home/koizumi/src/php.net/HEAD/php4/ext/mime_magic/mime_magic.c:348 #7 0x080b1f4e in zm_startup_mime_magic (type=1, module_number=9, tsrm_ls=0x8277f68) at /home/koizumi/src/php.net/HEAD/php4/ext/mime_magic/mime_magic.c:266 #8 0x0815a053 in zend_startup_module (module=0x82577a0) at /home/koizumi/src/php.net/HEAD/php4/Zend/zend_API.c:1008 #9 0x0812ec2b in php_startup_extensions (ptr=0x82621a0, count=15) at /home/koizumi/src/php.net/HEAD/php4/main/main.c:974 #10 0x08172732 in php_startup_internal_extensions () at main/internal_functions_cli.c:79 #11 0x0812f090 in php_module_startup (sf=0x8261f60, additional_modules=0x0, num_additional_modules=0) at /home/koizumi/src/php.net/HEAD/php4/main/main.c:1138 #12 0x08171955 in main (argc=1, argv=0xba94) at /home/koizumi/src/php.net/HEAD/php4/sapi/cli/php_cli.c:446 #13 0x40318507 in __libc_start_main (main=0x81717e8 main, argc=1, ubp_av=0xba94, init=0x80671f8 _init, fini=0x8172770 _fini, rtld_fini=0x4000dc14 _dl_fini, stack_end=0xba8c) at ../sysdeps/generic/libc-start.c:129 IMO php_error() should not be used in PHP_MINIT_FUNCTION. Any fix else? Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Andrei Zmievski [EMAIL PROTECTED] wrote: On Wed, 13 Nov 2002, Melvyn Sopacua wrote: FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. Explain to me please why --enable-mbstring is not enough. The userbase is not going to be a guinea-pig since only a subset of users will have a need for mbsting and those that do can use the switch. Those that don't will not even notice that it's not enabled. I think your words only a subset of users would be more accurate if it went only a subset of users who can write bug reports in English. Moriyoshi -Andrei http://www.gravitonic.com/ I must say I find television very educational. The minute somebody turns it on, I go to the library and read a good book. - Groucho Marx -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Oops, why didn't I notice such a trivial thing before asking a braindead question... Anyway I bet the problem should be gone by my patch that was just commited. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? It seems the mail() function is not avaliable on that system because sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Hmm, there might be no much need to fix this bug as it is not enabled by default... If the script still sefaults with my patch, I can no longer determine theplace at which it goes wrong just with your backtrace precisely, as it is apparently a double-free bug. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: I've just tried the latest CVS, it still crashes, the backtrace is same as before. Ilia On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote: Oops, why didn't I notice such a trivial thing before asking a braindead question... Anyway I bet the problem should be gone by my patch that was just commited. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? It seems the mail() function is not avaliable on that system because sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
--snip uhm, I don't think it works stable enough. I think the decision making went right, and I've got no more objection to that point. but I wonder how this could be certified as a stable module that is not widely used by the core developers? Moriyoshi Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch
It would be better to try inlining your patch also. I'm very interested in the patch. Moriyoshi Adrian Gartland [EMAIL PROTECTED] wrote: Attached is a patch which allows iso-2022-jp (jis) encoded text to be passed through htmlspecialchars when the character set is set to ISO-2022-JP. It should also fix a tiny bug I found in determine_charset code where len hadn't been set and then doing its charset map walk. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch
Could you make a patch diff'ed against the latest version of html.c in HEAD branch? determine_charset() issue which you pointed out seems to have been fixed already. Moriyoshi Adrian Gartland [EMAIL PROTECTED] wrote: http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch On 11 Nov 02, Jan Schneider [EMAIL PROTECTED] wrote: Zitat von Adrian Gartland [EMAIL PROTECTED]: Attached is a patch which allows iso-2022-jp (jis) encoded text to be passed through htmlspecialchars when the character set is set to ISO-2022-JP. It should also fix a tiny bug I found in determine_charset code where len hadn't been set and then doing its charset map walk. Your attachment didn't go through the mailing list filters. Please post a link where the patch can be downloaded. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Getting escape chars through the parser without warnings
Generally it's not considered to be a good idea to use iso-2022-jp encoding in your script because the scanner doesn't accept control codes in a string literal that is used to form shift sequences, and iso-2022-jp encoded strings may contain escape characters '\', which causes unexpected results. You can modify the scanner rules in Zend/zend_language_scanner.l and avoid those warnings indeed, but it won't help you write portable scripts. The current ZendEngine offers a limited support for multibyte encodings to solve such issues that can be enabled by specifying --enable-zend-multibyte option in configure, but it doesn't support any stateful encodings yet. (Though I'd like to see it fully supported) If you want to handle multibyte characters, you can use EUC-JP, Shift_JIS, or UTF-8 and convert the strings to the iso-2022-jp encoded ones either by mb_convert_encoding() or iconv() function whenever necessary. Or it is not enough ?? :) Moriyoshi Adrian Gartland [EMAIL PROTECTED] wrote: When using iso-2022-jp encoded strings within the I have to resort to doing error_reporting = ~E_COMPILE_WARNING to avoid getting a million Warning: Unexpected character in input: '' (ASCII=27) state=2 in in the page. iso-2022-jp uses escape characters go in and out of JIS charsets. Compile warnining are pretty important for development. Are there are less drastic ways of allowing the escape character through? As an example of its use, it goes something along the lines of ? $asTokenStrings[LANG:AGENDA:LONG_DAYNAME_MON] = ascii-like-text here ESC$B7nMKF|ESC(B ascii-like-text-here; echo $asTokenStrings[LANG:AGENDA:LONG_DAYNAME_MON]; ? -- Adrian Gartland - Senior Systems Engineer - TV Portal Team Oregan Networks UK Ltd Tel: +44 (0) 20 8846 0990 The White Building, 52-54 Glentham RoadFax: +44 (0) 20 8646 0999 Barnes, London. SW13 9JJ, United Kingdom WWW: http://www.oregan.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch
Thanks, I'll take a look at it. Moriyoshi Adrian Gartland [EMAIL PROTECTED] wrote: New patch applied against the current php4-latest.tar.gz, same location: http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch On 11 Nov 02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote: Could you make a patch diff'ed against the latest version of html.c in HEAD branch? determine_charset() issue which you pointed out seems to have been fixed already. Moriyoshi Adrian Gartland [EMAIL PROTECTED] wrote: http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch On 11 Nov 02, Jan Schneider [EMAIL PROTECTED] wrote: Zitat von Adrian Gartland [EMAIL PROTECTED]: Attached is a patch which allows iso-2022-jp (jis) encoded text to be passed through htmlspecialchars when the character set is set to ISO-2022-JP. It should also fix a tiny bug I found in determine_charset code where len hadn't been set and then doing its charset map walk. Your attachment didn't go through the mailing list filters. Please post a link where the patch can be downloaded. Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Adrian Gartland - Senior Systems Engineer - TV Portal Team Oregan Networks UK Ltd Tel: +44 (0) 20 8846 0990 The White Building, 52-54 Glentham RoadFax: +44 (0) 20 8646 0999 Barnes, London. SW13 9JJ, United Kingdom WWW: http://www.oregan.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_ADD_STRING patch
--snip
+fprintf(stderr, %s:%d\n, __FILE__,__LINE__);
What's this fprintf()? This seems to be put just for debugging purpose.
Moriyosh
return T_STRING;
}
-ST_DOUBLE_QUOTES,ST_BACKQUOTE,ST_HEREDOC{LABEL_OR_WHITESPACE} {
+ST_DOUBLE_QUOTES,ST_BACKQUOTE,ST_HEREDOC{LABEL} {
zend_copy_value(zendlval, yytext, yyleng);
zendlval-type = IS_STRING;
+fprintf(stderr, %s:%d\n, __FILE__,__LINE__);
return T_STRING;
}
@@ -1572,6 +1573,15 @@
}
}
+
+ST_DOUBLE_QUOTES,ST_BACKQUOTE,ST_HEREDOC{ESCAPED_AND_WHITESPACE} {
+ HANDLE_NEWLINES(yytext, yyleng);
+ zendlval-value.str.val = (char *) estrndup(yytext, yyleng);
+ zendlval-value.str.len = yyleng;
+ zendlval-type = IS_STRING;
+ return T_ENCAPSED_AND_WHITESPACE;
+}
+
ST_SINGLE_QUOTE([^'\\]|\\[^'\\])+ {
HANDLE_NEWLINES(yytext, yyleng);
zend_copy_value(zendlval, yytext, yyleng);
On Sunday, November 10, 2002, at 06:05 PM, Paul Nicholson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's the list, I don't think they allow attachmentsdo you have web
space
you could upload to?
On Sunday 10 November 2002 05:16 pm, Derick Rethans wrote:
On Sun, 10 Nov 2002, George Schlossnagle wrote:
For those who came to Dan my or Derick's talk at the Int. PHP
Conference, we both covered the bad inefficiency in the parser that
results in strings with variables in them being tokenized on
whitespace. This results in a huge number of unnecessary opcodes in
strings.
Attached (hopefully, as my new MUA seems to be fickle) is a first
shot
at a fix to the parser to keep this from happening, so that you
don't
need an optimizer to clear up this issue. I've tested this locally.
It still introduces a single unnecessary opcode after variable in
certain cases, but it works for me.
hmm, your MUA is getting senile :) no attachment...
Derick
- --
~Paul Nicholson
Design Specialist @ WebPower Design
The webthe way you want it!
[EMAIL PROTECTED]
www.webpowerdesign.net
It said uses Windows 98 or better, so I loaded Linux!
Registered Linux User #183202 using Register Linux System # 81891
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9zuZNDyXNIUN3+UQRAlYEAJ9PE5IKScOc+7/Kk1a71jJ87o7+EgCfV9z7
u+KZNZj2lZWzXmRiZmYrq4U=
=ChWV
-END PGP SIGNATURE-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
--snip but the mysql extension isn't invasive of other parts of the language, and can be safely disabled. I do not believe mbstring can be safely disabled, and i do not think that you have the transparent stuff disabled by default. Right, I'm sure those two cases are different. I just wanted to illustrate that there are quite a few aspects to think of before excluding / including an extension in a default build. There are definitely considerable number of people out there who will easily be bothered by that change. If you doubt it is safely disabled, please look through the relevant part of mbstring, and if you still have questions, please ask me then. the theory of mbstring is good; i am just concerned that a: it really hasn't been explained and discussed much on list, and b: there are two development trees, which just doesn't make sense. it's like some kind of underground secret society or something... I agree with you on these points. You may well consider me as a member of underground kong-foo coder syndicate, though I'm Japanese and not good at any marshal art stuff :) Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix for bug #19566
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.
And I don't think va_start() always has to be invoked.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
I am not sure if va_start can be called twice in a row (rekursive).
Manual does not say anything about that.
How about:
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 8 Nov 2002 09:32:48 -
@@ -722,9 +722,13 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
+ if (p == NULL) {
+ va_start(args, num_args);
+ va_end(args);
+ }
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +737,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
marcus
At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
Hi,
The attached patch is a probable fix for bug #19566. I guess the bug
is that va_list is not properly initialized before each callback function
call. I've tested it in PPC linux, and it works fine.
Regards,
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: mbstring and 4.3.0
PHP 4.3.0's Zend Engine also comes with SJIS awareness. It does not make sense to have SJIS awareness without mbstring also. (Need compile option to enable SJIS awareness) In addition, we'll have to take in account all of the double byte encodings in which second bytes of characters spans GL area (\x20-\x7e), like cp936(a MS variant of GB2312), cp949(ditto of KSC5601). Those encodings also need such awareness. Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix for bug #19566
Yep, the spec goes right. a corresponding va_end() dtor should be applied
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't
matter if ap is used between va_start() and va_end().
BTW, could anyone commit this patch if there seems no problem?
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
Some comments on ISO9899 standard
7.15.1.3-2 Read between the lines: without va_end the behaviour is undefined.
What ever that means i guess you have to call va_end and that requires
va_start.
7.15.1.4-3 Says do not call va_start twice without va_end.
marcus
ISO/IEC 9899:1999 (E) ©ISO/IEC
7.15.1.3 The va_end macro
Synopsis
1 #include stdarg.h
void va_end(va_list ap);
Description
2 The va_end macro facilitates a normal return from the function whose variable
argument list was referred to by the expansion of va_start, or the function
containing
the expansion of va_copy, that initialized the va_list ap. The va_end macro may
modify ap so that it is no longer usable (without an intervening invocation
of va_start
or va_copy). If there is no corresponding invocation of the va_start or va_copy
macro, or if the va_end macro is not invoked before the return, the behavior is
undefined.
Returns
3 The va_end macro returns no value.
7.15.1.4 The va_start macro
Synopsis
1 #include stdarg.h
void va_start(va_list ap, parmN);
Description
2 The va_start macro shall be invoked before any access to the unnamed
arguments.
3 The va_start macro initializes ap for subsequent use by va_arg and va_end.
va_start (or va_copy) shall not be invoked again for the same ap without an
intervening invocation of va_end for the same ap.
(...)
At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.
And I don't think va_start() always has to be invoked.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
I am not sure if va_start can be called twice in a row (rekursive).
Manual does not say anything about that.
How about:
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 8 Nov 2002 09:32:48 -
@@ -722,9 +722,13 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
+ if (p == NULL) {
+ va_start(args, num_args);
+ va_end(args);
+ }
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +737,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
marcus
At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
Hi,
The attached patch is a probable fix for bug #19566. I guess the bug
is that va_list is not properly initialized before each callback function
call. I've tested it in PPC linux, and it works fine.
Regards,
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix for bug #19566
done.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
Moriyoshi could you make a *.phpt file from the bug?
Attached is a new diff tested already. It also fixes a compiler warning.
Since i do not have Zend karma someone with karma should commit it
or give me karma.
marcus
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 8 Nov 2002 17:25:59 -
@@ -722,9 +722,9 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +733,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
@@ -1163,7 +1163,7 @@
ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2,
compare_func_t compar, zend_bool ordered TSRMLS_DC)
{
- Bucket *p1, *p2;
+ Bucket *p1, *p2 = NULL /* fixes warning */;
int result;
void *pData2;
At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
Yep, the spec goes right. a corresponding va_end() dtor should be applied
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't
matter if ap is used between va_start() and va_end().
BTW, could anyone commit this patch if there seems no problem?
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
Some comments on ISO9899 standard
7.15.1.3-2 Read between the lines: without va_end the behaviour is
undefined.
What ever that means i guess you have to call va_end and that requires
va_start.
7.15.1.4-3 Says do not call va_start twice without va_end.
marcus
ISO/IEC 9899:1999 (E) ©ISO/IEC
7.15.1.3 The va_end macro
Synopsis
1 #include stdarg.h
void va_end(va_list ap);
Description
2 The va_end macro facilitates a normal return from the function whose
variable
argument list was referred to by the expansion of va_start, or the
function
containing
the expansion of va_copy, that initialized the va_list ap. The va_end
macro may
modify ap so that it is no longer usable (without an intervening
invocation
of va_start
or va_copy). If there is no corresponding invocation of the va_start or
va_copy
macro, or if the va_end macro is not invoked before the return, the
behavior is
undefined.
Returns
3 The va_end macro returns no value.
7.15.1.4 The va_start macro
Synopsis
1 #include stdarg.h
void va_start(va_list ap, parmN);
Description
2 The va_start macro shall be invoked before any access to the unnamed
arguments.
3 The va_start macro initializes ap for subsequent use by va_arg and
va_end.
va_start (or va_copy) shall not be invoked again for the same ap without an
intervening invocation of va_end for the same ap.
(...)
At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.
And I don't think va_start() always has to be invoked.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
I am not sure if va_start can be called twice in a row (rekursive).
Manual does not say anything about that.
How about:
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 8 Nov 2002 09:32:48 -
@@ -722,9 +722,13 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
+ if (p == NULL) {
+ va_start(args, num_args);
+ va_end(args);
+ }
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +737,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht
Re: [PHP-DEV] [PATCH] Fix for bug #19566
var_args issue doesn't have much to do with the purpose of the patch. We
were perhaps just curious about the usage of va_start() and va_end().
And that warning reducer was later added by Marcus, so the first version
should look nice. What about it?
Moriyoshi
Andi Gutmans [EMAIL PROTECTED] wrote:
I haven't followed the thread. What is the problem with the var_args()?
Also, please don't commit the second part of the patch. The warning is due
to the compiler not understanding the code well enough. Functionality wise
there's no reason to NULL that variable. Live with the warning or upgrade
to a better compiler.
Andi
At 07:25 PM 11/8/2002 +0100, Derick Rethans wrote:
On Fri, 8 Nov 2002, Marcus Börger wrote:
Moriyoshi could you make a *.phpt file from the bug?
Attached is a new diff tested already. It also fixes a compiler warning.
Since i do not have Zend karma someone with karma should commit it
or give me karma.
I can commit this, after you fix the whitespace :)
Derick
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 - 1.93
+++ zend_hash.c 8 Nov 2002 17:25:59 -
@@ -722,9 +722,9 @@
HASH_PROTECT_RECURSION(ht);
- va_start(args, num_args);
p = ht-pListHead;
while (p != NULL) {
+ va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +733,8 @@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
@@ -1163,7 +1163,7 @@
ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2,
compare_func_t compar, zend_bool ordered TSRMLS_DC)
{
- Bucket *p1, *p2;
+ Bucket *p1, *p2 = NULL /* fixes warning */;
int result;
void *pData2;
At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
Yep, the spec goes right. a corresponding va_end() dtor should be applied
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't
matter if ap is used between va_start() and va_end().
BTW, could anyone commit this patch if there seems no problem?
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
Some comments on ISO9899 standard
7.15.1.3-2 Read between the lines: without va_end the behaviour is
undefined.
What ever that means i guess you have to call va_end and that
requires
va_start.
7.15.1.4-3 Says do not call va_start twice without va_end.
marcus
ISO/IEC 9899:1999 (E) ©ISO/IEC
7.15.1.3 The va_end macro
Synopsis
1 #include stdarg.h
void va_end(va_list ap);
Description
2 The va_end macro facilitates a normal return from the function whose
variable
argument list was referred to by the expansion of va_start, or the
function
containing
the expansion of va_copy, that initialized the va_list ap. The va_end
macro may
modify ap so that it is no longer usable (without an intervening
invocation
of va_start
or va_copy). If there is no corresponding invocation of the
va_start or
va_copy
macro, or if the va_end macro is not invoked before the return, the
behavior is
undefined.
Returns
3 The va_end macro returns no value.
7.15.1.4 The va_start macro
Synopsis
1 #include stdarg.h
void va_start(va_list ap, parmN);
Description
2 The va_start macro shall be invoked before any access to the unnamed
arguments.
3 The va_start macro initializes ap for subsequent use by va_arg and
va_end.
va_start (or va_copy) shall not be invoked again for the same ap
without an
intervening invocation of va_end for the same ap.
(...)
At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.
And I don't think va_start() always has to be invoked.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
I am not sure if va_start can be called twice in a row (rekursive).
Manual does not say anything about that.
How about:
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
Index: zend_hash.c
Re: [PHP-DEV] mbstring and 4.3.0
Hi, Now the transparent encoding conversion is disabled by default, and so is the function overloading. And the extension is not likely to cause any harm to other tests; recently some test failures related to output handlers were reported in fact, but the problem have been properly avoided. Then why do we even have to continue the same discussion? Is it the big deal how many people use mbstring? Now mbstring is not just for CJK people, because it also offers numerous unicode functionality. mb_convert_case(), contributed by Wez, is one of the examples. Besides I wonder why such dangerousness has not been warned up to now if that's the case. Moriyoshi Andrei Zmievski [EMAIL PROTECTED] wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? Comments are welcome. -Andrei http://www.gravitonic.com/ * We are not a clone. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bug #19943
This appears not a bug, but an expected behaviour for me.
Let's change it from Critial to Won't Fix or so on.
---
?php
$ragged = array();
for ($count = 0; $count 10; $count++) {
$ragged[$count] = $count;
$ragged[$count]['idx'] = $count;
}
for ($count = 0; $count 10; $count++) {
printf(single %d: %s\n, $count, $ragged[$count]);
printf(ragged %d: %s\n, $count, $ragged[$count]['idx']);
}
?
---
The above snippet is actually a variant of the following code:
---
?php
$ragged = array();
for ($count = 0; $count 10; $count++) {
$ragged[$count] = (string)$count;
$ragged[$count]{(int)'idx'} = (string)$count;
}
for ($count = 0; $count 10; $count++) {
printf(single %d: %s\n, $count, $ragged[$count]);
printf(ragged %d: %s\n, $count, $ragged[$count]{(int)'idx'});
}
?
---
Then, Cannot use a scalar value as an array warnings are due to
applications of braces for non-string variables.
But I can't still explain why leaks occured.
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #19943
I looked into it, and I've found you really got a point.
---
?php
$ragged = array();
$ragged[0] = a;
$ragged[0][0] = array(1);
var_dump($ragged);
?
---
The first script causes no leaks, while the second does:
---
?php
$ragged = array();
$ragged[0] = a;
$ragged[0][0] = (string)array(1);
var_dump($ragged);
?
---
Thanks for your insight.
Moriyoshi
Ilia A. [EMAIL PROTECTED] wrote:
I agree with you that this bug may not be critical, I am not certain why it
was marked as such, however I do believe this is a bug that should be fixed.
If my understand of the situation is correct, the memory leak is the result of
original $ragged[$count] = $count; expression. At this point ZE creates a
ZVAL that contains a 2 byte string value, number + \0.
When $ragged[$count]['idx'] = 'ragged '.$count; is executed, the original zval
containing a string is converted to an array. During this conversion the
string value is not freed and the result is a memory leak.
Ilia
On November 5, 2002 01:45 pm, Moriyoshi Koizumi wrote:
This appears not a bug, but an expected behaviour for me.
Let's change it from Critial to Won't Fix or so on.
---
?php
$ragged = array();
for ($count = 0; $count 10; $count++) {
$ragged[$count] = $count;
$ragged[$count]['idx'] = $count;
}
for ($count = 0; $count 10; $count++) {
printf(single %d: %s\n, $count, $ragged[$count]);
printf(ragged %d: %s\n, $count, $ragged[$count]['idx']);
}
?
---
The above snippet is actually a variant of the following code:
---
?php
$ragged = array();
for ($count = 0; $count 10; $count++) {
$ragged[$count] = (string)$count;
$ragged[$count]{(int)'idx'} = (string)$count;
}
for ($count = 0; $count 10; $count++) {
printf(single %d: %s\n, $count, $ragged[$count]);
printf(ragged %d: %s\n, $count, $ragged[$count]{(int)'idx'});
}
?
---
Then, Cannot use a scalar value as an array warnings are due to
applications of braces for non-string variables.
But I can't still explain why leaks occured.
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
