Re: [PHP-DEV] Apache2 SAPI
On March 6, 2003 11:19 am, Derick Rethans wrote: Our policy is not to merge new things to stable branches (which is PHP_4_3 now). True, however the apache2handler works much better then the existing apache2filter and as far as I can tell fixes at least 1 crash bug. There maybe more things it fixes, but I have not had the chance to test those yet. The only things on my wishlist is some CS cleanup better Apache info (akin to the one offered by Apache 1) and I hope to have a patch for those shortly. The only possible issue that I see with apache2handler, is that is requires the very latest Apache 2, 2.0.44. I think it would be in everyone's best interest if apache2handler was introduced in 4.3.X series probably replace the current apache2filter all together. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for wordwrap()
On March 6, 2003 06:52 am, Jedi/Sector One wrote: Hello. Maybe this is the intended behavior, but wordwrap()'s behavior is a bit illogical on PHP 4.3.1, as it does only break after a plain whitespace, not after punctuation, \n, etc. Here's a trivial sample : $a = ww\nphprules\nw; print wordwrap($a, 10, ' ', 10); Output : ww p hprules ww ww w The following trivial patch makes wordwrap() wrap after any non-alphanumeric charater. Output after application of that patch : ww phprules ww www Seems like the expected behavior to me, you are hardcoding the 'break' as ' ', meaning that no other character is considered a space hence, \n are being treated as part of the string rather then a string separator. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] imagesavealpha()
On March 5, 2003 12:18 am, Steven Brown wrote: I went to update the official gd library with my bug fixes so I could get them rolled back into PHP's without requiring PHP's gd diverge more, but it appears between the time PHP bundled gd and now that the gd people have fixed the most important of the truecolor problems that my patch used to fix - 2.0.11 managed to generate a truecolor boolean-transparent png. Problem is, PHP's bundled gd still fails. I poked around PHP's CVS, and the bundled libgd reports having already been synched with 2.0.11, but something must have been missed as it fails like pre-2.0.11. I'll try and look at what might have been missed in the sync when I get some more time. For now, I've added it as a bug, http://bugs.php.net/22544 . The bundled gd in php 5.0 has been sycnched with gd 2.0.11, this was not done for version 4.3.2. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] #php.bugs invite only?
On February 28, 2003 11:50 am, George Schlossnagle wrote: #php.bugs seems to be invite only now. How do I go about getting myself invited? It would appear someone had accidentaly set the channel to invite only, it is fixed now. Ilia -- 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/tokenizer tokenizer.c
On February 25, 2003 05:05 pm, Magnus M wrote: On Tue, 25 Feb 2003 14:45:26 -0500 J Smith [EMAIL PROTECTED] wrote: I get missing symbols like ZEND_INI_PARSER_POP_ENTRY and such, which should be defined in zend_ini.h.) Checking out php5 seemed to correct this. That is because php5 is HEAD. I have no idea what php4 is, except not-working. So you should checkout php5, not php4. PHP5 - co php5 PHP4 - co -rPHP_4_3 php4 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
On February 21, 2003 04:54 am, Wez Furlong wrote: Look in the archives for that guys original patch; it allowed doing something like this: $foo = array(); $foo[] = some text; $foo[] = more text; file_put_contents(file.txt, $foo); and also: file_put_contents(file.txt, $foo, $bar, $baz); I do see the advantage of allowing an array to be passed to allow the function to work as a reverse version of file(), however I am not certain about the usefulness of allowing passage of unlimited number of variables containing the strings to write. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
On February 21, 2003 05:00 am, Sascha Schumann wrote: Alternatively, I would suggest to teach the submitter of that patch regarding fopen, fwrite, implode. He might have overlooked those existing functions. That's what I like about PHP, you learn about new functions every single day. You are quite correct in saying that these three functions (which will be merged into one) are essentially a wrapper around fopen/fwrite (possibly implode) and fclose. However, IMO this wrapper is very useful since it simplifies commonly used code a great deal and even makes it slightly faster since the wrapper is in C rather then in PHP. Given that we already have file_get_contents(), a wrapper to do the opposite only makes sense to have. The previous discussion on the usability and the need for such a function seems gathered a fair bit of positive feedback as well. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
On February 21, 2003 09:38 am, Sascha Schumann wrote: implode) and fclose. However, IMO this wrapper is very useful since it simplifies commonly used code a great deal and even makes it slightly faster since the wrapper is in C rather then in PHP. Oh, come on. Put it into a utility library; this does not belong into the core of PHP. Or is your argument we already have so much bloat, a bit more is ok, too? This is merely a proposal, which anyone can support or not. Your choice is obviously the latter and that's fine, I do want to make it clear why I do want to see is part of PHP, whether my reasoning has merit or not is up to each person to decide for themselves. If other developers feel the same way you do, then this will definitely not be added and we'll have a precedent in the event someone else notices file_get_contents() and decides to write a function with opposing functionality. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] file_put_contents() / file_add_contents() ?
On February 20, 2003 02:51 pm, Sara Golemon wrote: Was it decided not to create these? Yes Is it simply a matter of noone having gotten around to it? Yes Am I paying too much attention to the voices in my head? Maybe ;) Joking aside, I do have a patch to implement the mentioned functionality at http://bb.prohost.org/file2.txt. If there are no objections I'll commit this to the CVS tommorow. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI long options
On February 15, 2003 12:16 pm, Marcus Börger wrote: 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. +1 from me, although I'd prefer is there was left out from PHP 4.3.X and was introduced as a 5.0 feature only. Ilia -- 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 file.c
On February 10, 2003 03:34 am, you wrote: On Sun, Feb 09, 2003 at 08:05:14PM -, Ilia Alshanetsky wrote : iliaa Sun Feb 9 15:05:14 2003 EDT Modified files: /php4/ext/standard file.c Log: Added feature request #14097 (option allowing file() command not to include line endings in it's output. As well as another option, which allows blank lines to be excluded from the output). Can we change this to not have two more optional parameters but re-use the existing one? We could turn the existing one into a flags parameter: 1 - use include path 2 - include new line 4 - skip_blank_lines This would not break BC and we don't need multiple optional parameters. Do we want to create constants for each option or simply accept integer values? Ilia -- 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 file.c
Attached is the proposed solution.
Ilia
Index: ext/standard/file.c
===
RCS file: /repository/php4/ext/standard/file.c,v
retrieving revision 1.299
diff -u -3 -p -r1.299 file.c
--- ext/standard/file.c 9 Feb 2003 20:43:05 - 1.299
+++ ext/standard/file.c 10 Feb 2003 15:46:19 -
@@ -180,6 +180,10 @@ PHP_MINIT_FUNCTION(file)
REGISTER_LONG_CONSTANT(STREAM_NOTIFY_SEVERITY_INFO,
PHP_STREAM_NOTIFY_SEVERITY_INFO, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(STREAM_NOTIFY_SEVERITY_WARN,
PHP_STREAM_NOTIFY_SEVERITY_WARN, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(STREAM_NOTIFY_SEVERITY_ERR,
PHP_STREAM_NOTIFY_SEVERITY_ERR, CONST_CS | CONST_PERSISTENT);
+
+ REGISTER_LONG_CONSTANT(STREAM_USE_INCLUDE_PATH, 1, CONST_CS |
+CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(STREAM_IGNORE_NEW_LINES, 2, CONST_CS |
+CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(STREAM_SKIP_EMPTY_LINES, 4, CONST_CS |
+CONST_PERSISTENT);
#ifdef HAVE_FNMATCH
REGISTER_LONG_CONSTANT(FNM_NOESCAPE, FNM_NOESCAPE, CONST_CS |
CONST_PERSISTENT);
@@ -444,7 +448,7 @@ PHP_FUNCTION(file_get_contents)
}
/* }}} */
-/* {{{ proto array file(string filename [, bool use_include_path [, bool
include_new_line [, bool skip_blank_lines]]])
+/* {{{ proto array file(string filename [, int flags])
Read entire file into an array */
#define PHP_FILE_BUF_SIZE 80
@@ -457,20 +461,26 @@ PHP_FUNCTION(file)
register int i = 0;
int target_len, len;
char eol_marker = '\n';
- zend_bool use_include_path = 0;
- zend_bool include_new_line = 1;
- zend_bool skip_blank_lines = 0;
+ long flags = 0;
+ zend_bool use_include_path;
+ zend_bool include_new_line;
+ zend_bool skip_blank_lines;
php_stream *stream;
/* Parse arguments */
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|bbb,
- filename, filename_len, use_include_path,
include_new_line, skip_blank_lines) == FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|l, filename,
+filename_len, flags) == FAILURE) {
return;
}
+ if (flags 0 || flags 7) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, '%d' flag is not
+supported., flags);
+ RETURN_FALSE;
+ }
+
+ use_include_path = flags 1;
+ include_new_line = flags 2;
+ skip_blank_lines = flags 4;
- stream = php_stream_open_wrapper(filename, rb,
- (use_include_path ? USE_PATH : 0) | ENFORCE_SAFE_MODE |
REPORT_ERRORS,
- NULL);
+ stream = php_stream_open_wrapper(filename, rb, (use_include_path ? USE_PATH
+: 0) | ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL);
if (!stream) {
RETURN_FALSE;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Apache 2.0 Handler module
The patch appears to work correctly with only one 'interesting' bug. When the virtual() function is used to include a php file or php files are included via the use of mod_include, random binary data is dumped on screen. This is particular to PHP files, as virtual() function can successfully include as many non-php files as you want without encountering this problem. Ilia -- 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 file.c
Here is the final revision of the patch.
Ilia
Index: ext/standard/file.c
===
RCS file: /repository/php4/ext/standard/file.c,v
retrieving revision 1.300
diff -u -3 -p -r1.300 file.c
--- ext/standard/file.c 9 Feb 2003 23:11:23 - 1.300
+++ ext/standard/file.c 10 Feb 2003 20:39:47 -
@@ -180,6 +180,10 @@ PHP_MINIT_FUNCTION(file)
REGISTER_LONG_CONSTANT(STREAM_NOTIFY_SEVERITY_INFO,
PHP_STREAM_NOTIFY_SEVERITY_INFO, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(STREAM_NOTIFY_SEVERITY_WARN,
PHP_STREAM_NOTIFY_SEVERITY_WARN, CONST_CS | CONST_PERSISTENT);
REGISTER_LONG_CONSTANT(STREAM_NOTIFY_SEVERITY_ERR,
PHP_STREAM_NOTIFY_SEVERITY_ERR, CONST_CS | CONST_PERSISTENT);
+
+ REGISTER_LONG_CONSTANT(FILE_USE_INCLUDE_PATH, PHP_FILE_USE_INCLUDE_PATH,
+CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(FILE_IGNORE_NEW_LINES, PHP_FILE_IGNORE_NEW_LINES,
+CONST_CS | CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT(FILE_SKIP_EMPTY_LINES, PHP_FILE_SKIP_EMPTY_LINES,
+CONST_CS | CONST_PERSISTENT);
#ifdef HAVE_FNMATCH
REGISTER_LONG_CONSTANT(FNM_NOESCAPE, FNM_NOESCAPE, CONST_CS |
CONST_PERSISTENT);
@@ -444,7 +448,7 @@ PHP_FUNCTION(file_get_contents)
}
/* }}} */
-/* {{{ proto array file(string filename [, bool use_include_path [, bool
include_new_line [, bool skip_blank_lines]]])
+/* {{{ proto array file(string filename [, int flags])
Read entire file into an array */
#define PHP_FILE_BUF_SIZE 80
@@ -457,20 +461,26 @@ PHP_FUNCTION(file)
register int i = 0;
int target_len, len;
char eol_marker = '\n';
- zend_bool use_include_path = 0;
- zend_bool include_new_line = 1;
- zend_bool skip_blank_lines = 0;
+ long flags = 0;
+ zend_bool use_include_path;
+ zend_bool include_new_line;
+ zend_bool skip_blank_lines;
php_stream *stream;
/* Parse arguments */
- if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|bbb,
- filename, filename_len, use_include_path,
include_new_line, skip_blank_lines) == FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|l, filename,
+filename_len, flags) == FAILURE) {
return;
}
+ if (flags 0 || flags 7) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, '%d' flag is not
+supported., flags);
+ RETURN_FALSE;
+ }
+
+ use_include_path = flags PHP_FILE_USE_INCLUDE_PATH;
+ include_new_line = !(flags PHP_FILE_IGNORE_NEW_LINES);
+ skip_blank_lines = flags PHP_FILE_SKIP_EMPTY_LINES;
- stream = php_stream_open_wrapper(filename, rb,
- (use_include_path ? USE_PATH : 0) | ENFORCE_SAFE_MODE |
REPORT_ERRORS,
- NULL);
+ stream = php_stream_open_wrapper(filename, rb, (use_include_path ? USE_PATH
+: 0) | ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL);
if (!stream) {
RETURN_FALSE;
}
Index: ext/standard/file.h
===
RCS file: /repository/php4/ext/standard/file.h,v
retrieving revision 1.74
diff -u -3 -p -r1.74 file.h
--- ext/standard/file.h 9 Feb 2003 20:43:05 - 1.74
+++ ext/standard/file.h 10 Feb 2003 20:39:47 -
@@ -87,6 +87,10 @@ PHPAPI int php_copy_file(char *src, char
#define META_DEF_BUFSIZE 8192
+#define PHP_FILE_USE_INCLUDE_PATH 1
+#define PHP_FILE_IGNORE_NEW_LINES 2
+#define PHP_FILE_SKIP_EMPTY_LINES 4
+
typedef enum _php_meta_tags_token {
TOK_EOF = 0,
TOK_OPENTAG,
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions
On February 6, 2003 11:17 am, David Gillies wrote: In a similar itch-scratching moment I whipped up a trivial PHP module that groks tzfile timezone files to give you the offset from GMT at any time in the Unix epoch. I needed this to preflight a bunch of data which had been gathered with a lot of disparate time zones into a single UTC version, but I thought it might merit further dissemination. Anyone interested? Certainly interesting functionality, however I think it would be better suited as a PECL extension or a PEAR class rather then being part of PHP's core. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
On January 30, 2003 04:55 pm, Jon Parise wrote: On Thu, Jan 30, 2003 at 01:44:27PM -0800, Sara Golemon wrote: You're not the first to voice this opinion. *I* feel str_ireplace is better as it follows the naming convention of module_function. Others feel stri_replace is better as that follows eregi_replace's style. I have no trouble going with whatever the majority feels is best. Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. +1 from me too, stri_replace sound like a function some users may have implemented them selves and we could end up breaking their code by introducing it. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
1. Not all users will notice the extra parameter easily. Will take some time. This modification will not appear until PHP 5 is released, by then this extra parameter (hopefully) will be well documented and people will be aware that it exists. Adding extra code, which virtually does the same thing IMHO is pointless and only creates a messy code that is difficult to maintain at a future point. 2. If some users made their own function called stri_replace, this is nothing that should be stopping from implementing it officially. In fact, to fix it would be as easy as encapsuling the function declaration in You are correct in the event of a user writing a new function, however consider what will happen if we are dealing with a old code, especially if it is no longer used just by the author but rather by a variety of other people not familiar with PHP code. The result is that after they or their ISPs upgrade to new PHP their scripts will stop working. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()
I may be wrong since I haven't profiled this, but my understanding is that str_replace is much faster than doing either of the regex replacements. For that reason alone, there is a use for it. Normally it would be quite faster, however once case sensitivity is added to the mix I believe the speed difference would be minimal. I've done some benchmarks and the speed difference between str_replace() and preg_replace() is only about 1/2 second in across 10 executions (5 replaces per instance). Another .6 of a second is added when preg_replace() is used with 'i' flag which makes it case insensitive. I have not benchmarked the stri_replace code but I imagine it would be in the same ballpark, meaning that we are adding a fairly large chunk of code for performance benefit of a 1 microsecond (1 millionth of a second) per instance. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()
On January 29, 2003 04:35 pm, Shane Caraveo wrote:
What's the benchmark code? How is the benchmark difference on large
text (ie. 100K of text) vs. small text (1K or smaller)?
Attached is the benchmark script that I've used. I've intentionally used
'small' strings, since that is what I imagine is most common usage of the
function.
Ilia
?php
$input[] = array('hfdhffndfafjdfjasfjas;fjdas;fjdsafjas;fjas', 'das', '1234');
$input[] = array('Used the form above or our advanced search page to make sure
nobody has reported the bug already.', 'or', 'OR');
$input[] = array('Once you\'ve double-checked that the bug you\'ve found
hasn\'t already been reported, and that you have collected all the information you
need to file an excellent bug report, you can do so on our bug reporting page.',
'XYS', '1234');
$input[] = array('dfkfjgjdsgjdgfd', 'dfkfjgjdsgjdgfd', '13243');
$input[] = array('xif pleh ot tnaw lliw enoemos taht gub a troper ot woh no
spit ruo daeR', 'Read our tips on how to report a bug that someone will want to help
fix', '13243');
function getmicrotime()
{
list($usec, $sec) = explode( ,microtime());
return ((float)$usec + (float)$sec);
}
$start = getmicrotime();
for ($i = 0; $i 10; $i++) {
foreach($input as $ent) {
str_replace($ent[1], $ent[2], $ent[0]);
}
}
$end = getmicrotime();
echo str_replace took: .($end - $start).\n;
foreach($input as $key = $val) {
$input[$key][1] = '!' . $val[1] . '!';
}
$start = getmicrotime();
for ($i = 0; $i 10; $i++) {
foreach($input as $ent) {
preg_replace($ent[1], $ent[2], $ent[0]);
}
}
$end = getmicrotime();
echo preg_replace took: .($end - $start).\n;
foreach($input as $key = $val) {
$input[$key][1] .= 'i';
}
$start = getmicrotime();
for ($i = 0; $i 10; $i++) {
foreach($input as $ent) {
preg_replace($ent[1], $ent[2], $ent[0]);
}
}
$end = getmicrotime();
echo preg_replace(i) took: .($end - $start).\n;
?
--
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 / configure.in /main php_ini.c php_scandir.c php_scandir.h /win32 readdir.c readdir.h
On January 27, 2003 04:12 pm, Sebastian Bergmann wrote: This broke the Win32 build. The attached patch works for me, but I'd like it reviewed before I commit. The header patch looks good, please commit it. Thanks. Ilia -- 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/gd gd.c /ext/gd/libgd gd.c gd.h gd_gd2.c gd_jpeg.c
On January 17, 2003 03:31 pm, Pierre-Alain Joye wrote: MFH'ing this commit should be a good thing. pierre Indeed, new GD introduces some functionality that is likely to make PHP generate invalid gd2 images, due to format not being specified. If no one has any objections I will MFH this commit into the 4.3.1 release. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
On January 15, 2003 10:14 am, Adam Wright wrote: Agreed in general. And whilst I'm here can I throw in my 2c about Bogus? Although an accurate description, it's hardly likely to be perceived as friendly. If you've taken the time to report a bug, even if you are in error, having it thrown back as Bogus seems pretty mean. How about a less antagonistic wording? I'd put forward something like NotaBug, which gives the same information without putting people's backs up. NotaBug or similar may lead to confusion. Quite often the issue may indeed be a bug, however it is not a bug in PHP and is therefor bogus. By marking such a bug report NotaBug may lead to confusion. IMO bogus is a fairly accurate representation of what the 'bogus' bug reports are, it is no more or less friendly then other bug status and is only a problem (less 'friendly') if you choose to make it such. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of NotAPHPBug? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not anymore. It is bogus, because the user chose not to search in the bug database for similar reports before posting their report. Surely you can agree that such a report is bogus. I suppose we could introduce a dozen different more 'friendly' statuses to replace the existing bogus status, but why? Surely not for the purpose of making users who don't do the necessary research before posting their bug reports feel better about themselves. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
Consider the following, there are a lot more PHP users then PHP developers and considering that not all PHP developers are actively involved in the bug solving process (many are involved with PEAR/PECL/Documentation and so on) there are very few people actively working on resolving bugs. This makes the time of these people very valuable, people who post invalid bug reports eat up that valuable time and by doing so not only cause a loss of bug fixing time but also disillusion developers and often make them move on to more exciting things like writing new code. Perhaps a slightly less then an absolutely polite approach, will make those people reconsider their bug posting technique and do a little research before deciding that their non-working script constitutes a valid bug report and start wasting everyone's time. Most of the time when a bug is marked bogus the developer will indicate why the bug is bogus, so that the user is not left in the dark. All that said, I see nothing especially inflammatory about 'bogus' and I do not believe it is the intent of the developers to insult or degrade the user who had posted a bogus report. The 'invalid' status that was proposed, in my opinion, just as 'unfriendly' as bogus. Ilia -- 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
I imagine that strings greater then 2 billion characters are fairly rare, so I think it would be a good idea to revert the change as per Sascha's suggestion. This is a fairly old limitation and I think no one will miss this feature. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] string functions
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
Re: [PHP-DEV] Patch for #21309 - memory + php_error_docref.
I've already sent Stefan a patch for this problems as well as other issues in the ftp extension. Ilia On January 2, 2003 08:29 pm, [EMAIL PROTECTED] wrote: Hello, Even if this bug was assigned to sesser, this is a patch that fix the memory managment and that removes perror and replace it by php_error_docref(). It's also online if the mailing is denying it: http://nicos.worldakt.com/ftp_c.patch. Any comment appreciated, thanks. Note: it will probably need some reviews. Regards. M.CHAILLAN Nicolas [EMAIL PROTECTED] www.WorldAKT.com Hébergement de sites internets. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UNIX file command
On January 3, 2003 12:18 pm, Michael Montero wrote: Is there a built in function in PHP that mimicks the UNIX file command? For instance, I run : file blah.jpg and I get this: blah.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), 72 x 72 For identifying images there is already getimagesize() that will fetch information about number of commonly used file formats. There is also a mime_magic extension that uses the same database as the one used by UNIX file command to identify a variety of files. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
On December 30, 2002 02:04 pm, Andrei Zmievski wrote: I concur. Please remember to update NEWS on the branch. Could you please add a section for the branch (4.3.1?) in the news file. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3
On December 30, 2002 02:17 pm, Edin Kadribasic wrote: Could you please add a section for the branch (4.3.1?) in the news file. Isn't it already there? There is one for 4.4 (possibly to be renamed 5), but I don't see a 4.3.X section. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposed fix for bug #21149
The current implementation of php_register_variable_ex() improperly handles
situations when the name of the variable passed via GET/POST/COOKIES contains
a '[' or it's urlencoded equivalent. The result is a small memory leak
(number of chars between '[' and '=' +1) and invalid data inside the
GET/POST/COOKIES array.
The proposed patch makes php_register_variable_ex aware that [ may not be
terminated and adds handling for such conditions. The end result is that the
code no longer leaks memory can support variable passed via
GET/POST/COOKIES with '[' in their names.
Ilia
P.S. This patch is against HEAD and is not intended for 4.3.0
Index: php_variables.c
===
RCS file: /repository/php4/main/php_variables.c,v
retrieving revision 1.46
diff -u -3 -p -r1.46 php_variables.c
--- php_variables.c 7 Dec 2002 16:05:27 - 1.46
+++ php_variables.c 24 Dec 2002 00:44:59 -
@@ -120,7 +120,27 @@ PHPAPI void php_register_variable_ex(cha
while (1) {
if (is_array) {
- char *escaped_index;
+ char *escaped_index = NULL, *index_s;
+ int new_idx_len = 0;
+
+ ip++;
+ index_s = ip;
+ if (isspace(*ip)) {
+ ip++;
+ }
+ if (*ip==']') {
+ index_s = NULL;
+ } else {
+ ip = strchr(ip, ']');
+ if (!ip) {
+ *(index_s - 1) = '[';
+ index_len = var_len = strlen(var);
+ goto plain_var;
+ return;
+ }
+ *ip = 0;
+ new_idx_len = strlen(index_s);
+ }
if (!index) {
MAKE_STD_ZVAL(gpc_element);
@@ -148,22 +168,9 @@ PHPAPI void php_register_variable_ex(cha
}
symtable1 = Z_ARRVAL_PP(gpc_element_p);
/* ip pointed to the '[' character, now obtain the key */
- index = ++ip;
- index_len = 0;
- if (*ip=='\n' || *ip=='\r' || *ip=='\t' || *ip==' ') {
- ip++;
- }
- if (*ip==']') {
- index = NULL;
- } else {
- ip = strchr(ip, ']');
- if (!ip) {
- php_error_docref(NULL TSRMLS_CC, E_WARNING,
Missing ] in %s variable, var);
- return;
- }
- *ip = 0;
- index_len = strlen(index);
- }
+ index = index_s;
+ index_len = new_idx_len;
+
ip++;
if (*ip=='[') {
is_array = 1;
@@ -172,6 +179,7 @@ PHPAPI void php_register_variable_ex(cha
is_array = 0;
}
} else {
+plain_var:
MAKE_STD_ZVAL(gpc_element);
gpc_element-value = val-value;
Z_TYPE_P(gpc_element) = Z_TYPE_P(val);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21060 [Opn-Bgs]: range() gives warning and returns false when low == high
Since we are so close to the 4.3.0 the 'fix' for range() will not make it to the 4.3.0 release. However, for the 4.4.0 release I've committed an extensive patch that greatly extends the functionality of range(). This includes support for float modifier, detection of numeric values passed as strings and of course the handling for the high == low condition. Ilia On December 20, 2002 10:49 pm, Chandrashekhar Bhosle wrote: On Fri, 20 Dec 2002 09:44:49 -0500 Ilia A. [EMAIL PROTECTED] wrote: What would be an output then, array() ? range(2,4) gives array(2,3,4); range(2,3) gives array(2,3); range(2,2) gives array(2); Good idea, +1. I'll prepare a patch. http://freedomink.org/code/php/patches/array.c.patch My patch submitted with the bug report does exactly that. (Returns array(low) if high == low.) I would appreciate if you had a look at it. - cnb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #21060 [Opn-Bgs]: range() gives warning and returns false when low == high
On December 20, 2002 06:35 am, you wrote: On 20 Dec 2002 [EMAIL PROTECTED] wrote: ID: 21060 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Linux 2.4.18 PHP Version: 4CVS-2002-12-16 (dev) New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Nothing wrong with this behaviour, the low high point are the same, hence the false output indicating failure. Actually, I think this is a bug, and I see the usefulnes in having the floor and bottom having the same value. I can write up a patch if needed. What would be an output then, array() ? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21060 [Opn-Bgs]: range() gives warning and returns false when low == high
On December 20, 2002 09:37 am, you wrote: On Fri, 20 Dec 2002, Ilia A. wrote: On December 20, 2002 06:35 am, you wrote: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Nothing wrong with this behaviour, the low high point are the same, hence the false output indicating failure. Actually, I think this is a bug, and I see the usefulnes in having the floor and bottom having the same value. I can write up a patch if needed. What would be an output then, array() ? range(2,4) gives array(2,3,4); range(2,3) gives array(2,3); range(2,2) gives array(2); Good idea, +1. I'll prepare a patch. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20972 [Opn-Csd]: make fails during gd.c
This is a different bug (xpm) caused by a bug in the external GD library, this particular bug has been solved in the CVS. Unless you've patched your GD with gif write support you have nothing to gain from not using the bundled library, which offers more functionality and is more stable. The problem with free/gd_free is likely due to you having 2 sets of the GD library on your computer. This confuses the check, because the headers do not correspond with the library itself. Ilia On December 12, 2002 04:37 pm, electroteque wrote: i'm sorry this is not fixed , i have RC03 In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89: /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function `_php_image_output_ctx': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:105: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_type': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1156: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1163: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1345: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) i can honestly say checking for a particular version will not help instead check for versions less than the version that requires gd_free which is gd-2.0.8 #if HAVE_LIBGD204 io_ctx-gd_free(io_ctx); #else io_ctx-free(io_ctx); #endif i cant see where this define is coming from HAVE_LIBGD204 ?? [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... ID: 20972 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux - 2.4.18 - SuSE 7.2 PHP Version: 4.3.0RC3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-12 13:46:02] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=compile gcc -I/usr/local/src/gd-1.8.4/ -Iext/gd/ -I/usr/local/src/apache2/php-4.3.0RC3/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/apache2/php-4.3.0RC3/include -I/usr/local/src/apache2/php-4.3.0RC3/main -I/usr/local/src/apache2/php-4.3.0RC3 -I/usr/local/apache2/include -I/usr/local/src/apache2/php-4.3.0RC3/Zend -I/usr/local/ssl/include -I/usr/local/include -I/usr/local/src/gd-1.8.4/ -I/usr/include/mysql -I/usr/local/verisign/payflowpro/linux/lib -I/usr/local/src/apache2/php-4.3.0RC3/ext/xml/expat -I/usr/local/src/apache2/php-4.3.0RC3/TSRM -g -O2 -prefer-pic -c /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /usr/local/src/apache2/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) make: *** [ext/gd/gd.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=20972edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20972 [Opn-Csd]: make fails during gd.c
When I say CV,S I am referring to the latest version of the PHP_4_3 tree, you can download snapshots of that tree (generated every 2 hours) from http://snaps.php.net Ilia On December 12, 2002 04:55 pm, electroteque wrote: sure i do but i have prefixed where gd is so it shouldnt be confused, its obviously not checking for 2.0.8 ? i have made my patches to gd s/php/php-4.3.0RC3/TSRM -g -O2 -prefer-pic -c /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c -o ext/gd/gd.lo /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) hmm RC2 never gave me this after i renamed the functions so its something else, i'm going to try --with-gd without a prefix and see what happens, are you talking the latest snapshot when u say cvs, saying cvs is too vague , as 0RC3 is the latest stable i have also tried the snapshots, but still showing errors Ilia A. [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... This is a different bug (xpm) caused by a bug in the external GD library, this particular bug has been solved in the CVS. Unless you've patched your GD with gif write support you have nothing to gain from not using the bundled library, which offers more functionality and is more stable. The problem with free/gd_free is likely due to you having 2 sets of the GD library on your computer. This confuses the check, because the headers do not correspond with the library itself. Ilia On December 12, 2002 04:37 pm, electroteque wrote: i'm sorry this is not fixed , i have RC03 In file included from /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:89: /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c: In function `_php_image_output_ctx': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:73: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd_ctx.c:105: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_type': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1156: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1163: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `_php_image_create_from': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1345: structure has no member named `free' /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1363: warning: assignment makes pointer from integer without a cast /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c: In function `zif_imagecreatefromxpm': /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: `gdImageCreateFromXpm' undeclared (first use in this function) /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: (Each undeclared identifier is reported only once /usr/src/sources/php/php-4.3.0RC3/ext/gd/gd.c:1433: for each function it appears in.) i can honestly say checking for a particular version will not help instead check for versions less than the version that requires gd_free which is gd-2.0.8 #if HAVE_LIBGD204 io_ctx-gd_free(io_ctx); #else io_ctx-free(io_ctx); #endif i cant see where this define is coming from HAVE_LIBGD204 ?? [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... ID: 20972 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux - 2.4.18 - SuSE 7.2 PHP Version: 4.3.0RC3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-12 13:46:02] [EMAIL PROTECTED] /bin/sh libtool
Re: [PHP-DEV] Re: #20972 [Opn-Csd]: make fails during gd.c
On December 12, 2002 06:13 pm, Mike Robinson wrote: Ilia A. wrote: This is a different bug (xpm) caused by a bug in the external GD library, this particular bug has been solved in the CVS. Unless you've patched your GD with gif write support you have nothing to gain from not using the bundled library, which offers more functionality and is more stable. The problem with free/gd_free is likely due to you having 2 sets of the GD library on your computer. This confuses the check, because the headers do not correspond with the library itself. Is the xpm fix going to make it into 4.3 then? Yes. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register_shutdown_function = register_offline_function
Known issue, the original patch for this problem had to be reveted since it broke the handling of mulit-line CVS fields that are quoted. I am now working on a more permanent fix. Ilia On December 5, 2002 11:39 am, Brian Moon wrote: Ok, I reopened the bug. It fails with latest CVS. [root@dealnews php4-200212051430]# ./sapi/cgi/php-cgi csv.php Content-type: text/html X-Powered-By: PHP/4.4.0-dev Array ( [0] = 6 [1] = 7 [2] = 8 [3] = line1 ) Segmentation fault Brian Moon dealnews.com - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 10:00 AM Subject: Re: [PHP-DEV] register_shutdown_function = register_offline_function | Hey Brain, | | watch your attitude, we're not here to solve your problems. fgetcvs is | not broken at all, it has been fixed recently. If you still think it's | broken file a bugreport. | | Derick | | On Thu, 5 Dec 2002, Brian Moon wrote: | Has the new function been created yet and if not when? | | We have just spent 2 weeks investigating why our pages started dragging to | find out that register_shutdown_function is BROKE. I am a little | discouraged from what I have read on this. It seems that BC is only a | concern when the right person likes the old way it worked. When the right | people don't like the way things work, BC is thrown out the window and code | is broken. fgetcsv is broke and has been broke IMO. It causes segfaults. | Read the archives. But because it would break BC (and the orig author likes | the way it workds) it stays unchanged. | | As for the new function,If we are creating a new function, we should create | a new one for the NEW behavior. This is the same thing that happened with | mysql_fetch_array. At first, it returned an associative array and | mysql_fetch_row returned a numerical array. Then someone said, I want both | in one call, so, someone decided that mysql_fetch_array should return both. | Well, people complained (me included) and the solution was make it take an | optional param to designate the array type with both being the default. | Now, we all know that assoc should have been the default. So, i wrote | mysql_fetch_assoc, got it commited and never looked back on that one. | | Thanks for the time. | | Brian Moon | dealnews.com | | | | | -- | PHP Development Mailing List http://www.php.net/ | To unsubscribe, visit: http://www.php.net/unsub.php | | -- | | - | 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] New SNMP function names
Consistency is always good and adding aliases for newly added functions seems like a recipe for bloat confusion. +1 on the proposed changes. Ilia On December 4, 2002 08:49 am, Derick Rethans wrote: Hello, while browsing the CVS I found that the following functions were added to the CVS recently: + PHP_FE(snmpv3get, NULL) + PHP_FE(snmpv3walk, NULL) + PHP_FE(snmpv3realwalk, NULL) + PHP_FALIAS(snmpv3walkoid, snmpv3realwalk, NULL) + PHP_FE(snmpv3set, NULL) C But those functionnames don't adhere to our nameing guidelines. As those are new functions I propose to change them to the following, to be more consistent with all other functions: snmpv3get - snmp3_get snmpv3walk - snmp3_walk snmpv3realwalk - snmp3_real_walk (or snmp3_walk_oid) snmpv3set - snmp3_get also, there is no need to introduce an alias for a newly created function so I guess we just should drop it. I'd like to make those proposed changes ASAP as they are also added in the PHP_4_3 branch which gets closer to release everyday. regards, Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
On November 29, 2002 01:05 am, Sara Golemon wrote: I disagree with this, the current behaviour is imho wrong. mailto: is a url, rejecting the patch because it introduces a special case, is not a good thing. parse_url() is for _all_ url's, not just http:// url's, and besides, the current syntax for mailto is completely valid, and should be parsed anyway. (ie, a special case shouldn't be required if the url parser was rfc compliant). PHP's php_url_parse() function is not in any way limited to http:// as you claim, it support a large variety of valid URLs, take a look at the very extensive test for parse_url() function located here: ext/standard/tests/strings/url_t.phpt. Even the regular expression described in RFC 2396 does not recognize mailto: any differently the our very own parse_url(). It looks like php_url_parse can be modified to return user and host for mailto schemes without making it a 'special case', but that would also remove the current 'path' index which would break existing PHP code ((bad)). So we can (A) put in a special case, or (B) not modify the function at all. Either way leaves someone unhappy so in the absence of a majority I can't help but do nothing. This request will have to remain open, at least for now. Users requests all kinds of features all the time, just because someone will be unhappy because their request is not implemented is hardly a reason to implement it. As a rule, special cases are bad, if you REALLY think this is useful functionality we are better off adding a parse_email() function, who's job would be to break email addresses into parts. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
On November 29, 2002 12:41 pm, Sara Golemon wrote: It looks like php_url_parse can be modified to return user and host for mailto schemes without making it a 'special case', but that would also remove the current 'path' index which would break existing PHP code ((bad)). So we can (A) put in a special case, or (B) not modify the function at all. Either way leaves someone unhappy so in the absence of a majority I can't help but do nothing. This request will have to remain open, at least for now. Users requests all kinds of features all the time, just because someone will be unhappy because their request is not implemented is hardly a reason to implement it. As a rule, special cases are bad, if you REALLY think this is useful functionality we are better off adding a parse_email() function, who's job would be to break email addresses into parts. I'm not so much worried about the user in this case, a few explodes will keep them happy. I'm more worried about the behavior of parse_url being just plain lacking. mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be entitled to everybit as much parsing as http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value The ONLY real concern here, and reason for not fixing php_url_parse, comes in the fact that 'path' would no longer contain '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would likely break existing scripts. Perhaps the compromise is to create a new function 'parse_url_rfc' (name could be better) which behaves correctly (without having special cases). Then add a note to the manpage for parse_url saying to use parse_url_rfc instead, and eventually deprecate parse_url (perhaps with PHP 5.0). No. parse_url_rfc would be misleading because it would not follow RFC. There are special rules for scheme:, scheme:/ and scheme://, your suggested patch would actually break RFC, since mailto: is already parsed properly according to RFC. E-mail addresses are not urls, if we want to offer an email parser it should be separate function parse_email or something similar, there is no need to pollute php_parse_url() with hacks for non-intended functionality. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 28, 2002 12:56 pm, Maxim Maletsky wrote: Shall we still consider introducing error codes to PHP? IMO, it does not represent any enormous maintenance increase while has some positive points. Do you have an effecient manner in which to implement the introduction of error codes? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
I am not so sure that adding special cases for things like mailto: and so on
is a good idea. The code works identically to how it worked in 4.2.3 and
prior.
Ilia
On November 27, 2002 04:19 pm, Sara Pollita Golemon wrote:
While waiting for opinions on Bug#20460 I went ahead and addressed #20308.
User complains that parse_url returns the full email address in 'path'
element. Makes reference to documents which claim it should return 'user'
and 'host' element.
To address this request and maintain backward compatability I wrote a
patch to split the 'path' element in to 'host' and 'user' elements then
return all three.
Ex:
*current behavior*
print_r(parse_url(mailto:[EMAIL PROTECTED];));
Array (
[scheme] = mailto
[path] = [EMAIL PROTECTED]
}
*new behavior*
print_r(parse_url(mailto:[EMAIL PROTECTED];));
Array (
[scheme] = mailto
[path] = [EMAIL PROTECTED]
[user] = pollita
[host] = php.net
}
If there are no objections I'll commit this change.
Index: url.c
===
RCS file: /repository/php4/ext/standard/url.c,v
retrieving revision 1.59
diff -u -r1.59 url.c
--- url.c 14 Nov 2002 13:40:14 - 1.59
+++ url.c 27 Nov 2002 20:44:25 -
@@ -267,6 +267,26 @@
php_replace_controlchars(ret-path);
}
+ if (strcmp(ret-scheme,mailto) == 0) {
+ s = estrndup(ret-path, strlen(ret-path));
+ ue = s + strlen(ret-path);
+ p = s + 1;
+ /* a mailto starting with @ would be malformed, but let's keep it clean
*/ + if (s[0] == '@') {
+ s[0] = '\0';
+ }
+ /* scan for @ to separate user from host */
+ while (p ue p[-1] != '\0') {
+ if (p[0] == '@') {
+ p[0] = '\0';
+ }
+ p++;
+ }
+ ret-user = s;
+ /* the free() process in php_url_free will segfault if we don't
duplicate this string value */
+ ret-host = estrndup(p, (ue-p));
+ }
+
return ret;
}
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
On November 27, 2002 04:45 pm, Sara Pollita Golemon wrote: That was one of the comments I was looking for Is this really necessary? After all the user can certainly use explode() to take it apart. I'm not against giving him that answer, it was just a quick patch to write... Is that a -1 then? Yup, -1 from me. I am not so sure that adding special cases for things like mailto: and so on is a good idea. The code works identically to how it worked in 4.2.3 and prior. Ilia On November 27, 2002 04:19 pm, Sara Pollita Golemon wrote: While waiting for opinions on Bug#20460 I went ahead and addressed #20308. User complains that parse_url returns the full email address in 'path' element. Makes reference to documents which claim it should return 'user' and 'host' element. To address this request and maintain backward compatability I wrote a patch to split the 'path' element in to 'host' and 'user' elements then return all three. Ex: *current behavior* print_r(parse_url(mailto:[EMAIL PROTECTED];)); Array ( [scheme] = mailto [path] = [EMAIL PROTECTED] } *new behavior* print_r(parse_url(mailto:[EMAIL PROTECTED];)); Array ( [scheme] = mailto [path] = [EMAIL PROTECTED] [user] = pollita [host] = php.net } If there are no objections I'll commit this change. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug #20308 (Feature Request)
On November 27, 2002 04:32 pm, Sterling Hughes wrote: On November 27, 2002 04:45 pm, Sara Pollita Golemon wrote: That was one of the comments I was looking for Is this really necessary? After all the user can certainly use explode() to take it apart. I'm not against giving him that answer, it was just a quick patch to write... Is that a -1 then? Yup, -1 from me. I disagree with this, the current behaviour is imho wrong. mailto: is a url, rejecting the patch because it introduces a special case, is not a good thing. parse_url() is for _all_ url's, not just http:// url's, and besides, the current syntax for mailto is completely valid, and should be parsed anyway. (ie, a special case shouldn't be required if the url parser was rfc compliant). PHP's php_url_parse() function is not in any way limited to http:// as you claim, it support a large variety of valid URLs, take a look at the very extensive test for parse_url() function located here: ext/standard/tests/strings/url_t.phpt. Even the regular expression described in RFC 2396 does not recognize mailto: any differently the our very own parse_url(). Ilia -Sterling I am not so sure that adding special cases for things like mailto: and so on is a good idea. The code works identically to how it worked in 4.2.3 and prior. Ilia On November 27, 2002 04:19 pm, Sara Pollita Golemon wrote: While waiting for opinions on Bug#20460 I went ahead and addressed #20308. User complains that parse_url returns the full email address in 'path' element. Makes reference to documents which claim it should return 'user' and 'host' element. To address this request and maintain backward compatability I wrote a patch to split the 'path' element in to 'host' and 'user' elements then return all three. Ex: *current behavior* print_r(parse_url(mailto:[EMAIL PROTECTED];)); Array ( [scheme] = mailto [path] = [EMAIL PROTECTED] } *new behavior* print_r(parse_url(mailto:[EMAIL PROTECTED];)); Array ( [scheme] = mailto [path] = [EMAIL PROTECTED] [user] = pollita [host] = php.net } If there are no objections I'll commit this change. -- 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] Redirect on Error (not localisation)
On November 26, 2002 03:09 pm, John Coggeshall wrote: Unless told otherwise, I'm already planning on making a few changes and committing. I for one, am -1 on the idea as I am sure some other developers are too. Let's first clearly tally who is for and who is against the idea before adding it to the CVS. Ilia John -Original Message- From: Ivan Ristic [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 2:50 PM To: [EMAIL PROTECTED] Cc: 'James Aylett'; 'PHP Developers Mailing List' Subject: [PHP-DEV] Redirect on Error (not localisation) Anyway... So what of my actual patch we were discussing at some point? I never got a real answer as to if it would be suitable to commit. I have changed the subject of the message in an effort to separate the discussion on the Redirect on Fatal Error feature (the subject of this email) from the localisation discussion. ... As a reminder, we are discussing a patch that will redirect the user to another page when a fatal or a parse error occurs (parse errors can be caught with lint, fatal can't). The redirection will allow developers to: * Show a decent page to the user (instead of letting them see a blank or incomplete page) * Send a message to themselves that something strange has happened (allowing them to react quickly, instead of having to install log watch software for notification purposes (and many people cannot do that as they do not have control over the servers)) As far as I am aware, there is not a single reason not to have this feature. Some people seem not to like it, but that is fine; with no performance or stability risks, if you don't want to use the feature - you won't be affected. On the other hand, I will be extremely happy to have it under my belt as yet another tool I can use to make my software run better. Please don't tell me that I wouldn't need this feature if I programmed perfectly. Errors happen all the time, no matter what you do trying to prevent them. Bye, Ivan -- 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] Build of bundled GD broken on Win32
Fixed. On November 25, 2002 06:06 am, Sebastian Bergmann wrote: gd.obj: error LNK2001: Unresolved external symbol: _gdImageCreateFromGd2Part gd.obj: error LNK2001: Unresolved external symbol: _gdImageCreateFromGd2PartCtx gd.obj: error LNK2001: Unresolved external symbol: _gdImageGd2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 01:58 pm, John Coggeshall wrote: Multi-lingual error codes open's up pandora's box, let's not go there. I have to disagree with you here Sterling. Worrying about support for non-english errors in php-general, etc is a bad, bad excuse not to implement them. The benefits of a completely constant-based error system (with human-friendly errors just because we like them) is worth consideration and I really feel is a positive addition to PHP. The only pandora's box your worried about (at least from the sound of your e-mail) was your inbox size ;) Or am I missing something? In conclusion to both (imho):: English is fine. Uncatcheable parse errors is also fine. I for one completely agree with Sterling. Localization of errors in wrong because it creates an inconsistent behavior, each user will see a different error depending on the locale they are using. This will not only make things confusing but make resolving bugs errors so much more difficult for both PHP developers as well as users themselves. Consider that a hosting provider in France decides to compile their PHP with error messages localized in French. Suddenly all their non-French speaking clients of that provider cannot understand what the PHP error messages say. Not only that. but what will happen with distributable PHP applications when a user reports an error to the developer(s) and that error is localized. 9 out of 10 times the developer will ignore the report because he has no clue what the error means. Most common fatal error is a parse error, it is the result of carelessness. In a production enviroment there is no reason why it should happen. I see no reason to add complex redirection code which only obfuscated the cause of the problem. Most people don't associate error 500 with a PHP process, this is usually something reserved to CGI, meaning that people will look for the cause of the problem in the completely wrong place. As for adding XML and other nastiness, why?!?! Error reporting should be dead simple and not involve compile time or realtime parsing and so on. Ideally the error reporting mechanism would set an error code inside $php_errno and then a user can either handle the error themselves in a appropriate manner or use something akin to php_errno(); to display the text explanation for the error itself (this is a bastardized version of the error reporting mechanism proposed by Stig Bakken). Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 07:57 pm, Maxim Maletsky wrote: On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes [EMAIL PROTECTED] wrote: Educate users to speak the base amount of english required, I18N'ing the language is just going to lead to headaches from a user perspective (incorrect translations, slower performance, translations for english speakers) and a developer perspective (having to lookup tokens, understanding another language, getting bug reports with horrible error messages). That is why we have error codes :) Are you saying that Oracle is wrong giving the ability to localize even SQL error messages? These does not have to ever happen, but in my Italian team the guys are simply rocking - they find out instantly what they did wrong to a query because it is in their language. Oracle is by far the most bloated piece of software in existence, adopting ideas from it is hardly a good idea. It is so complex, that perhaps localization was the only way they could make it usable for international users. Sets the language to what you speak and you will develop faster wherever you're coming from. And the next logical step from that would be to develop in the language you speak and this is how you get PHP code that makes Perl look good. Right now code written by French developer can be understood by a Chinese developer, with the eventual evolution of your suggestion understanding code would require the knowledge of the language the author decided to use in addition to PHP. As of bug reports - as long as every error has its own error code everyone in the world can find out what the error means. How different is that from simply translating the documentation? Bugs imply a problem with either PHP itself or in some cases an application written in PHP. In those cases the person resolving the bug will be the original developer who if he cannot understand the problem will pipe it to /dev/null. I don't know how you evaluate your time, but most people just don't have the time to look up error code XYZ in the big error-code codebook. With PHP we already have enough difficulty resolving the bugs we have, adding more complexity by introducing i18n will only lead to more valid reports being ignored because no one has the time to 'translate' the problem. I mean consider the PHP documentation project, most translations are notoriously behind and even the English translation need much work. Realistically, I think that even if you did introduce i18n in error message most would still remain in English with maybe 20-30% of messages being translated in popular locales like German and French and even lower in less common locales. With such low translation level you are only going to introduce confusion, which is the exact opposite of what you are trying to do. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 08:15 pm, Maxim Maletsky wrote: On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) That's arguable, there are many people who would say the same about IBM's DB2. According to TPC (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp) Microsoft SQL Server 2000 is faster and has lower cost per transaction. So claims about greatness of Oracle and greatly exaggerated. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 08:24 pm, Maxim Maletsky wrote:
On Mon, 25 Nov 2002 20:14:56 -0500 Ilia A. [EMAIL PROTECTED] wrote:
On November 25, 2002 07:57 pm, Maxim Maletsky wrote:
On Mon, 25 Nov 2002 15:21:06 -0500 Sterling Hughes
[EMAIL PROTECTED]
wrote:
Educate users to speak the base amount of english required, I18N'ing
the language is just going to lead to headaches from a user
perspective (incorrect translations, slower performance, translations
for english speakers) and a developer perspective (having to lookup
tokens, understanding another language, getting bug reports with
horrible error messages).
That is why we have error codes :)
Are you saying that Oracle is wrong giving the ability to localize even
SQL error messages? These does not have to ever happen, but in my
Italian team the guys are simply rocking - they find out instantly what
they did wrong to a query because it is in their language.
Oracle is by far the most bloated piece of software in existence,
adopting ideas from it is hardly a good idea. It is so complex, that
perhaps localization was the only way they could make it usable for
international users.
Complex because does a lot - it is, in a way, an Operating Sytems on its
own.. But, as you can say yourself - localization of errors does help.
Sets the language to what you speak and you will develop faster
wherever you're coming from.
And the next logical step from that would be to develop in the language
you speak and this is how you get PHP code that makes Perl look good.
Right now code written by French developer can be understood by a Chinese
developer, with the eventual evolution of your suggestion understanding
code would require the knowledge of the language the author decided to
use in addition to PHP.
Hello?/?? we're talking about errors here, not page content.
Hopefuly that does not become the same :)
Actually I am talking in users using their native language to name their
functions variables and actually write them in that language. So, a person
could use ISO-8859-15 encoding or cp1251 encoding because afterall it is
easier to understand the code that way.
When you get an error while developing, seeing it in your own language,
whichever it is - English, Chinese, Russian or Japanese - it will be the
language you will set it to and thus the best for you, developer. What's
so wrong with that?
Because when I work on a server where the language is set to Japanese which, I
unfortunately do not know, I will have no idea what the error is.
As of bug reports - as long as every error has its own error code
everyone in the world can find out what the error means. How different
is that from simply translating the documentation?
Bugs imply a problem with either PHP itself or in some cases an
application written in PHP. In those cases the person resolving the bug
will be the original developer who if he cannot understand the problem
will pipe it to /dev/null. I don't know how you evaluate your time, but
most people just don't have the time to look up error code XYZ in the big
error-code codebook.
php_error(225);
whereas 255 is defined some string in many languages appering like this:
Warning (255): Undefined Variable.
One writes in bugs.php.net:
Non dovrei ricevere questo errore:
Attenzione (225): Variabile non predefinita.
in questo codice:
if($var) {
}
perche?
And you, without speaking Italian, will be just as helpful to him.
Wrong, I've read the first 5 words, the lexical parser in my head failed to
interpret the message and accordingly I've moved on. Maybe someone will be
more patient, but that is unlikely. Eventually someone may indeed look and
address the report, but that may take weeks and possibly months for a problem
I may or some other person could've addressed right away had it been in
English. Bottom line is that people who are not getting payed to do support
will apply minimum effort to understand the user, remember most open source
developers are volunteers, making their life difficult certainly is not in
the user's best interest.
Realistically, I think that even if you did introduce i18n in error
message most would still remain in English with maybe 20-30% of messages
being translated in popular locales like German and French and even lower
in less common locales. With such low translation level you are only
going to introduce confusion, which is the exact opposite of what you are
trying to do.
I don't think so. There are much less error strings than manual pages -
these got tranlsated well, and so will error string.
Really? Let's see on average each function generates @ least one warning
message, so we have @least as many warnings as we have functions. Warning
messages get constantly re-arranged, by having a separate database for them
making changes to warning messages will become more complex
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 08:44 pm, George Schlossnagle wrote: Is your claim that db2 has no international error messages? It does, or did last I checked. Or was it that SQLServer doesn't either (it does as well). Uhm, did I say anything about i18n in DB2 or SQLServer, no. I merely pointed out that Oracle's status as most powerful database is in the eye of the beholder. Ilia On Monday, November 25, 2002, at 08:24 PM, Ilia A. wrote: On November 25, 2002 08:15 pm, Maxim Maletsky wrote: On Tue, 26 Nov 2002 00:30:55 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: Just forget this. I'm not native english speaker, but I REALLY don't want to see any errors in any other language but english. (does Perl/Python/etc have multi-lingual errors btw?) --Jani The world's most powerful database server does - Oracle. And, just type something out of the place and you will get them dozens :) That's arguable, there are many people who would say the same about IBM's DB2. According to TPC (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp) Microsoft SQL Server 2000 is faster and has lower cost per transaction. So claims about greatness of Oracle and greatly exaggerated. 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] [PATCH] Redirect on Error
On November 25, 2002 08:29 pm, Maxim Maletsky wrote: Who cares? I am an Oracle fun, but this is still not my point. My point is that oracle, as arguable as can be, thinks about marketing its product. They biggest sales point, in fact, is not the usability and nor even the documentation. Though, as a matter of fact, every usage of its SQL and PLSQL programming is ported to every language. My point was that just because application XYZ does something, it does not mean PHP should do it to. Plus, comparing a database to a scripting language, how about we compare it to something equivalent, like Perl? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 08:53 pm, Maxim Maletsky wrote: Well, in this case you would just add locales like you do with dates, for example. Meaning that you will be applying the locale logic in real time? Have you considered what kind of performance degradation this will entail? And you, without speaking Italian, will be just as helpful to him. Wrong, I've read the first 5 words, the lexical parser in my head failed to interpret the message and accordingly I've moved on. Maybe someone will be more patient, but that is unlikely. Eventually someone may indeed look and address the report, but that may take weeks and possibly months for a problem I may or some other person could've addressed right away had it been in English. Bottom line is that people who are not getting payed to do support will apply minimum effort to understand the user, remember most open source developers are volunteers, making their life difficult certainly is not in the user's best interest. Again, having error codes gives and solves more than adds problems. [snip] I don't agree with you, Ilia. Errors are string, even a part of the documentation. They need to be also translated whether it does or does not make a developer modifying an XML file. There can be several ways accomplishing it. I am more that just +1 for globalization or run time reporting. I have nothing against error codes, that is a good idea. I just have a problem with XML errors and i18n in error messages generated by PHP. When do we draw the line, how about function prototypes inside the C source code? Should those be translated as well, it would make developing PHP by example easier, no? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 09:09 pm, Philip Olson wrote: [snip] Really? Let's see on average each function generates @ least one warning message, so we have @least as many warnings as we have functions. Warning messages get constantly re-arranged, by having a separate database for them making changes to warning messages will become more complex then writing the actual code. So, people will in many cases cut corners and just RETURN_FALSE; without giving a detailed explanation. Most developers like to write code, not modify XML files and write essays for proof look @ http://www.zend.com/phpfunc/statistics.php, according to that page ~14% of all functions in PHP are not documented in the English language. Just to defend phpdoc a bit, this statistic is based on a php manual generated on April 25, 2002, which is when zend.com/manual/ was last updated. Also, missing functions are almost all from experimental and/or cvs only functions. Sure your point is still valid (php-dev would rather code than document) but the numbers are a little misleading... and that's why such a great phpdoc team exists :) phpdoc team does a great job, I am sure translating and fixing docs is not a fun job and any effort put towards such a goal should be commended. However, your task list will double if not more should the i18n error message be added. Even now it appears there is too much to do, juding by the fact that # of documentation bug reports seems to increase rather then decrease when compared to the actual source code bugs. By assigning more work to same number of people will lead to even less work being accomplished, so just from a logistical stand point i18n errors are not a good idea. Ilia P.S. Most if not all cvs only functions will be a part of 4.3.0. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 09:22 pm, Maxim Maletsky wrote: On Mon, 25 Nov 2002 21:11:37 -0500 Ilia A. [EMAIL PROTECTED] wrote: On November 25, 2002 08:53 pm, Maxim Maletsky wrote: Well, in this case you would just add locales like you do with dates, for example. Meaning that you will be applying the locale logic in real time? Have you considered what kind of performance degradation this will entail? Of course it will. But, this is an option, so one can localize them if wishes. Like in cases when you want English while your co-workers use another language and you cannot change the main php settings If my co-workers and I cannot communicate in the same language we will probably go our separate ways within a week. Afterall, how can we work together if we don't have a common language between us. By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? XML is what I think would be the best for the whole thing of managing errors. It could be integrated into the docs, parallelly translated into multiple language, adding extra flexibility and features growth. This can be also useful for modifying errors for users themselves if they wish to. It would probably flexible solution, but terribly complex. Let's consider the process, a developer decides to add sanity check with a warning. They write the code and now need to modify an XML file with an error message, reference the XML entry from their code. Commit all this to CVS and hope they did not messup. Also, how and when XML parsing will be merged inserted into C code? Won't you be adding an XML parser decency to PHP? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 09:59 pm, George Schlossnagle wrote: By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? Why would this need to kill your performance if you're not throwing errors? Because errors need to be loaded into memory by some mechanism, stored in a hash table? Meaning that during startup I will be penalized for this process. Hash table has it own overhead as well meaning that PHP memory usage will increase, for a server running 200-300 apache children constantly even a small increase will count. This will also make PHP shell scripting impractical due to the high start costs of a PHP binary. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
On November 25, 2002 09:52 pm, John Coggeshall wrote: I am completely +1 to the concept of taking error codes out of the PHP core and replacing them with an XML document, period. I say this regardless of language considerations -- I just think for everyone involved having a XML document which controls the errors that are generated is just a good idea. As I layed out before, I'd like to replace the current error system with a error-code based system (see my earlier thread for information on what I was thinking on this)... Now, on to the question of localization... I am definitely -1 for this idea. XML is a buzzword, it is good in some cases not so good in others, definitely not a one size fits all solution. In PHP's case it would add decency on an XML parser, make life of developers adding, modifying, removing error messages difficult and just like the documentation will seriously lag behind the primary (English) localization. The biggest complaint that people seem to have regarding localization is that the QA team and such would suddenly find themselves trying to dechipher french in order to track down a bug... It's funny, you guys don't want errors in a forigen language because they are too difficult to understand yet you don't mind forcing the developers who don't speak english to do the same? This is exactly my point. I feel that, with a proper implementation, PHP can be globalized WITHOUT making lives difficult for the development team. That is just one complaint. I personally have a BIG issue with this due to performance considerations. IMO PHP already has more then enough overhead just adding more to the pile will drive some users away. RAD (Rapid Application Development) gets you only so far eventually for large scale applications speed becomes essential and if Perl, Python, C can offer it then those languages will be picked over PHP. What I propose is based off of my first proposal of Error codes based on Maxim's suggestions. Basically, I'd like to see errors broken down into three separate code constants: TYPE, MODULE, AND ERROR... Where TYPE would be E_ERROR, etc, MODULE would be the extension causing the error (M_PHP_CORE, etc) and ERROR would be the actual error that occurred (i.e. E_PHP_CORE_PARSE). Notice that I am using descriptive names for the error constants. This is because I suggest that although each individual error message is localized to German, French, etc, every error message displays this descriptive errorcode... Ie.. What will happen to localized error message when the charset of the page they are displayed on does not support the charset required for proper rendering of the text? Most likely gibberish. Error (module: E_ERROR, M_PHP_CORE): A parse error occurred at line 34 of file foobar.php (E_PHP_CORE_PARSE) Störung (Modul: E_ERROR, M_PHP_CORE): Eine Satzgliederung Störung trat an Linie 34 der Akte foobar.php auf (E_PHP_CORE_PARSE) Erreur (modules: E_ERROR, M_PHP_CORE): A erreur parse occurred AT ligne 34 of fichier foobar.php (E_PHP_CORE_PARSE) If you have a constant for every error would that not mean you will need to register hundreds if not thousands of constants at run time at an enormous CPU memory cost? This would be simple to implement, and no more of a hassle to maintain that what already exists however still provides enough information to the development/QA teams (we know the type, the module, and the actual error which occurred) yet still allows the developers who aren't english-speaking to still have some clue as to what the heck happened with their script. How do you figure that it would be just as easy to maintain? Right now adding an error is just a matter of writing the English text inside the C file I am working on. By having messages localized they'll need to be stored else where XML, gettext database and so on... meaning that there is already more for the developer to do. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 10:30 pm, George Schlossnagle wrote: There is no proposed patch to affect all these changes. There are fine ways to print errors that don't necessitate having them loaded at run time. They could be in a dbm file, or even a flat file hierarchy and loaded on demand. This would not be as fast as a hash table, but when you're actually printing errors, a slight overhead seems acceptable (to me, ymmv) If we were talking about a one time script that is execute and forget then you are absolutely right. But what about if a web server enviroment where a child/thread can remain in memory indefinitely. Or a web hosting enviroment where the admin has no control over the script of the users, loading (unloading?) of the error messages database will add overall overhead non the less. This is also not as easy as it sounds, for example a gettext a commonly used tool for localizations, is not thread safe, so we are looking at having to design a error localization mechanism with a thread safe disk database system. On Monday, November 25, 2002, at 10:27 PM, Ilia A. wrote: On November 25, 2002 09:59 pm, George Schlossnagle wrote: By the way, could you please advise by how much I will need to increase the power of my server(s) to maintain the same level of performance? Why would this need to kill your performance if you're not throwing errors? Because errors need to be loaded into memory by some mechanism, stored in a hash table? Meaning that during startup I will be penalized for this process. Hash table has it own overhead as well meaning that PHP memory usage will increase, for a server running 200-300 apache children constantly even a small increase will count. This will also make PHP shell scripting impractical due to the high start costs of a PHP binary. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 10:59 pm, Sascha Schumann wrote: On Mon, 25 Nov 2002, Ilia A. wrote: On November 25, 2002 08:29 pm, Maxim Maletsky wrote: Who cares? I am an Oracle fun, but this is still not my point. My point is that oracle, as arguable as can be, thinks about marketing its product. They biggest sales point, in fact, is not the usability and nor even the documentation. Though, as a matter of fact, every usage of its SQL and PLSQL programming is ported to every language. My point was that just because application XYZ does something, it does not mean PHP should do it to. Plus, comparing a database to a scripting language, how about we compare it to something equivalent, like Perl? Neither Python nor Perl are web-centered, or easily available (as in writing their first script) for newbies. They are hardly comparably in terms of catering to the same set of people for whom localized error messages would be a big bonus. Neither are web centered, but are fairly commonly used in web applications via mod_python, mod_perl and of course cgi at least they are closer then DBMS and RDBMS systems to the subject matter. As far as a newbie language, many people start with things like Visual Basic, Perl and Java. The latter being increasingly popular in school environments. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
On November 25, 2002 10:57 pm, George Schlossnagle wrote: On Monday, November 25, 2002, at 10:43 PM, Ilia A. wrote: On November 25, 2002 10:30 pm, George Schlossnagle wrote: There is no proposed patch to affect all these changes. There are fine ways to print errors that don't necessitate having them loaded at run time. They could be in a dbm file, or even a flat file hierarchy and loaded on demand. This would not be as fast as a hash table, but when you're actually printing errors, a slight overhead seems acceptable (to me, ymmv) If we were talking about a one time script that is execute and forget then you are absolutely right. But what about if a web server enviroment where a child/thread can remain in memory indefinitely. Or a web hosting enviroment where the admin has no control over the script of the users, loading (unloading?) of the error messages database will add overall overhead non the less. dbm lookups are fast, as are (to a lesser extent) file system lookups. Neither consume any process memory. Neither require an entire database to be loaded, simply to have the entry looked up in them. Nearly any singular operation is fast, the question is what happens when it is done often. For a database stored on disk we are talking at least 2-3 drive seeks + reading of meta information at the start of the database. While it may be negligible for a single process it does add up. Given that this done rarely (hopefuly) it would not result in major performance loss, however there will be a performance loss non the less. Well, fortunately, this being an open-source project this burden need not lie with you if you don't want it to. I dislike the idea because I believe this idea is going to make PHP more confusing and ultimately harder to use, which is the exact opposite of what this change attempts to accomplish. Fortunately this being an open-source project it is also possible to make your own version free of bloat :) Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On November 18, 2002 07:44 am, Derick Rethans wrote: On Mon, 18 Nov 2002, Marcus Börger wrote: Brian could you create a short test for the segfault? It would help us finding out the problems. For now I think it's very wise to remove all the e*() memory functions from the branch, it's not strictly needed and we need to be very careful not to emalloc data that should be preserved accross requests. That's why I've a patch read to remove the e*() stuff for the branch so that we have a lot of time for the 4.4/5.0 version to check all these things out. +1 I think we don't have nearly enough time to fully test this change in gd before 4.3.0 is out, so this will need to wait till the next release. We've used gd for many years without auditing it's memory, I am sure another half a year or so won't too much difference. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mime_magic segfaults
Why was rb changed to rt? Ilia On November 15, 2002 06:58 am, Moriyoshi Koizumi wrote: 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 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mime_magic segfaults
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.13
diff -u -3 -p -r1.13 mime_magic.c
--- mime_magic.c4 Oct 2002 19:01:34 - 1.13
+++ mime_magic.c15 Nov 2002 03:24:35 -
-304,6 +304,11 PHP_FUNCTION(mime_content_type)
return;
}
+ if ((int) conf-magic == -1) {
+zend_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,13 +348,12 static int apprentice(void)
magic_server_config_rec *conf = mime_global;
fname = conf-magicfile; // todo cwd?
-f = fopen(fname, r);
+f = fopen(fname, rb);
if (f == NULL) {
- php_error(E_WARNING,
-MODNAME : can't read magic file %s, fname);
- return -1;
+ (int) conf-magic = -1;
+ return -1;
}
-
+
/* set up the magic list (empty) */
conf-magic = conf-last = NULL;
--
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
On November 13, 2002 07:50 am, 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. If mbstring proves to be as popular as some people say many people will take a chance and enable the extension while compiling given the size of PHP user base that should be more then enough people to discover bugs in the extension. However, there is no need to put some 2 million (or whatever the latest netcraft data is) hosts running PHP at risk by enabling it by default. Unfortunately every extension has bugs, but usually such bugs do not affect PHP overall performance, mbstring is different, a bug in it can affect PHP behavior. Because of this I believe we need exercise extreme caution before even considering enabling it by default. * Getting real bug reports is a good thing(tm). Breaking compilation because of sloppy symbol protections sucks(r). The number of bugs should not be a factor in this scenario, because once it becomes core, you're gonna have to deal with them anyway. Given prior history, when an extension has many bugs or is being heavily modified it was/is marked experimental and kept so several months even after the development was halted and bugs were addressed. Why an important extension like mbstring should be different? * Enabling by default for 4.3.0 is actually the best point in time, unless there's going to be a 4.4.0. You don't want this to be done in 5.0.0, because the new OO layer, other new features and especially BC-breaking issues will have to be focused on. (I'm not saying PHP 5 is intending to break BC - just that there is a high probability issues arrise, which we're not foreseeable). I think there is a 60% chance that they'll be further 4.3.X releases after 4.3.0 simply because this release represents a fair number of large changes and most likely will require several bug fixing releases. It is even remotly possible that 4.4.X may happen, but I am in no position to make such promises so, this is something I can only make educated guesses on. A x.x.0 release is the best release to do it in, because people who demand a high level of stability already will skip it and still it will have a large enough audience to flush out the bugs nobody thought of. Sure, but if the people who try it get burnt by the mbstring extension, you can be sure that in the next release at least half of them will disable it straight off. And if these people are hosting providers, they'll refuse the turn it on for their customers because they would consider it a hindrance to the stability of their PHP. You are going to accomplish the exact opposite of what you've set out to do. All in all - I think we should enable the parts mentioned by Wez, in RC1. The default behavior should be it's compiled in, but doesn't impact any functions. If there is a large number of distinct bug reports, then it's obvious the extension is not mature enough for it and because of the schedule (not the number) it should be disabled in the final release I am lazy and I am sure many other people are too, certain features like overloading make life rather simple in that regard. You can be sure many people who are as lazy as I am will turn it on. Because to them it would be an important feature. Consider if a person is trying to make large, existing application support multi-byte, with overload they can avoid changing a large chunks of their code, they'll try it. If it does not work, many will simply drop mbstring because for all its wonderful functionality, it does not work as advertised. So, saying lets enable part A because it is stable and disable part B and C, just does not work. It is either all or nothing. Ilia -- 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
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
Re: [PHP-DEV] mbstring and 4.3.0
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
Re: [PHP-DEV] mbstring and 4.3.0
Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia -- 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
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
On November 12, 2002 09:42 pm, Marcus Börger wrote: At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. Through the course of my work I have to deal with many ISPs from all over the world, of all sizes. In my experience over 60% of ISPs have non-default PHP configuration. And most of the remaining 40% are more then willing to add additional extension(s), especially if those extensions do not require external libraries. Keep in mind most ISPs will not upgrade to 4.3.0 and will most likely wait for a few releases past 4.3.0 to upgrade. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. Any extension is useful if it was not the author(s) would not have spent time and effort writing it. The fact it is useful, does not automatically imply we should enable it by default. The question on the agenda wether ever single user who upgrades needs to have mbstring enabled by default. My belief that unless majority of PHP users will benefit from this extension we should not enable it by default. All the arguments in favor had not convinced me that this would be the case. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. mbstring has many dedicated developers whom are doing excellent maintaining and upgrading this extension. Which at the moment makes mbstring very much a work in progress, there is hardly a day without at least one or two CVS commits to it. Since this is a work in progress, it is simply not safe to enable it by default if we want to claim any sort of stability for 4.3.0 release. There is a chance it'll work out, but IMHO there is even a greater chance it will cause problems like it did in 4.2.3 with mangling of POST requests, 4.3.0 will have more then enough new stuff as is. Perhaps by the next major release, mbstring will be a lot more mature and thoroughly tested in production enviroment. At that point we can discuss this issue again and consider whether this extension has merit for most users and based on that decide whether or not to enable it by default. Ilia -- 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
On November 13, 2002 12:28 am, Moriyoshi Koizumi wrote: 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. I'll look into the problem in more detail tommorow. Ilia 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
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] PHP Snaps
On November 11, 2002 05:07 pm, James Cox wrote: I can certainly set this up. any preference for timeformat? (bearing in mind we use unix date) date -R | sed -e 's/ /_/g' Would be the best format IMHO. Ilia -- james Is it possible to increase build time from 4 hours to 2 hours and use a time format that displays the timezone? marcus At 00:34 11.11.2002, James Cox wrote: Snaps are back! The snapserver is back up and alive, with both unix and win32 snaps... -- james -- James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Quality Assurance 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] PHP Snaps
On November 11, 2002 05:16 pm, Edin Kadribasic wrote: On Monday 11 November 2002 23:14, Ilia A. wrote: On November 11, 2002 05:07 pm, James Cox wrote: I can certainly set this up. any preference for timeformat? (bearing in mind we use unix date) date -R | sed -e 's/ /_/g' Would be the best format IMHO. Nice format but it doesn't sort well in directory listings :) True, but we only have about a dosen files and with a human readable format directory file sorting is not as relevant IMHO. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Snaps
Well there are a number of issues. First of all current snapshot listing is a regular apache directory listing, which causes files with names longer then X amount of characters to be cut off. If we decide to add any readable timestamp to the file we'd need to use some PHP script to display the files. In this case it would be trivial to make the script sort the files by their creation date. Ilia On November 11, 2002 05:23 pm, Edin Kadribasic wrote: On Monday 11 November 2002 23:20, Ilia A. wrote: Nice format but it doesn't sort well in directory listings :) True, but we only have about a dosen files and with a human readable format directory file sorting is not as relevant IMHO. I disagree. The task of picking the latest sapshot (or one before it) becomes difficult with that verbose time format. For me its much easier to pick the last file listed (or one before it). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Configuration Patches
Attached are two patches that I've written to address a number of issues I've
come across while testing PHP on Solaris.
The first patch (alloca.txt) eliminated a warning message due to the fact that
that on Solaris and Tru64 alloca() is defined in a separate header, alloca.h,
which is not included. The current check only attempts to include this header
is the compiler in not GNUC, I came across the problem while using gcc 3.2,
which is becoming quite common on Solaris.
The second patch (flex.txt) is a flex check that ensures we are using the GNU
flex 2.5.4 (released in 1997, so it is safe to assume any recent distro has
it). If it is not found the configure script gives an advisory warning
similar to the one we give for bison. Only an advisory is given, because
unless PHP is compiled from CVS, flex is not needed.
This check is needed, because for example, the stock lexer installer on Sun
Os, does not support the -P flag needed by PHP and even though it passes
existing configure checks, it fails when it comes to generating the .c files.
Are there any objection to the integration of those 2 patches?
Ilia
Index: zend.h
===
RCS file: /repository/Zend/zend.h,v
retrieving revision 1.163
diff -u -r1.163 zend.h
--- zend.h 9 Oct 2002 06:19:10 - 1.163
+++ zend.h 9 Nov 2002 18:11:31 -
-117,11 +117,13
# define ZEND_EXTENSIONS_SUPPORT 0
#endif
+#if HAVE_ALLOCA_H !defined(_ALLOCA_H)
+# include alloca.h
+#endif
+
/* AIX requires this to be the first thing in the file. */
#ifndef __GNUC__
-# if HAVE_ALLOCA_H
-# include alloca.h
-# else
+# ifndef HAVE_ALLOCA_H
# ifdef _AIX
#pragma alloca
# else
Index: configure.in
===
RCS file: /repository/php4/configure.in,v
retrieving revision 1.395
diff -u -r1.395 configure.in
--- configure.in4 Nov 2002 20:08:08 - 1.395
+++ configure.in9 Nov 2002 18:12:46 -
-158,6 +158,12
LEX_CFLAGS=-DYY_USE_CONST
fi
+AC_MSG_CHECKING([flex version])
+set `$LEX -V | grep 'version' | cut -d ' ' -f 3 | sed -e 's/\./ /g' | sed -e 's/[^0-9
+]//g'`
+if test ${1} != 2 -o ${2} != 5 -o ${3} -lt 4; then
+AC_MSG_WARN(You will need flex 2.5.4 or later if you want to regenerate
+Zend/PHP lexical parsers.)
+fi
+AC_MSG_RESULT(${1}.${2}.${3} (ok))
dnl Platform-specific compile settings.
dnl -
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Please help document headers_sent()
On November 6, 2002 07:10 pm, Philip Olson wrote:
I get a Segmentation fault with this script using
PHP CLI:
?php
headers_sent($file, $line);
?
philiprock:~$ php test.php
Segmentation fault
That's when no headers are sent before the call. But if
headers are sent beforehand, it works:
The crash has been fixed in the CVS. PHP CLI cannot send any headers because
it is not ment for a webserver enviroment. While CGI, is mostly geared
towards web servers and by default will try to send headers.
Ilia
?php
print foo\n;
headers_sent($file, $line);
print $file : $line\n;
?
philiprock:~$ php test.php
foo
test.php : 2
With a fairly (a few weeks old) version of PHP CLI.
I am unable to do further tests at this time, in fact,
I am unable to build HEAD (it dies). Only CLI seems
to be affected, CGI works either way. Haven't
tested mod.
Regards,
Philip Olson
P.s. If no headers were sent, in CGI, $line gets
the value int 0. $file is an empty string.
On Wed, 6 Nov 2002, Philip Olson wrote:
On Wed, 6 Nov 2002, Wez Furlong wrote:
if (headers_sent($file, $line)) {
echo headers were sent by $file:$line;
}
[snip]
Hello Wez-
Ahh, that makes sense. I was a little off
base on that one! :) Will add an example now.
Regards,
Philip
--
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] Win32 snaps ext/xslt
It appears that the Sablotron needs to be upgraded as well, since xstl cannot
be compiled due to 2 missing flags
('SAB_DISABLE_STRIPPING','SAB_IGNORE_DOC_NOT_FOUND'), which I am guessing are
only defined in the newer library.
Ilia
On November 5, 2002 08:01 am, Edin Kadribasic wrote:
Any chance the sablot library on the snaps server could be
upgraded?
The library has been upgraded to 0.96.
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #19943
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
Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)
The patch does work and memory leak goes away after it is applied. There is
another problem that I've just noticed. If you increase the loop from 10 to
100 then you'll see that the $ragged[$count]['idx'] value is always the 1st
character of the $ragged[$count] value.
If a var_dump of an array is made you'll see that the array stucture looks
something like this:
array(100) {
[0]=
string(1) 0
[1]=
string(1) 1
[2]=
string(1) 2
[3]=
string(1) 3
[4]=
string(1) 4
And so on, no mention of 'idx'. I believe since idx is not found,value of 0 is
used, which causes the look up to go after $ragged[$count][0], returning the
1st character of the $ragged[$count] value.
IMHO the fix for this problem should give the user a warning message
indicating that they are not doing something correctly. ZE already would give
you such an error, if were you try:
?php
$z = 1;
$ragged = array();
$ragged[0] = $z;
$ragged[0][0] = array(1);
var_dump($ragged);
?
Ilia
P.S. After your patch is applied the test script you've posted, results in the
following error:
---
Zend/zend_execute.c(376) : Block 0x084EC268 status:
Beginning: Cached (allocated on Zend/zend_execute.c:1985, 44 bytes)
End: OK
---
On November 5, 2002 05:48 pm, Moriyoshi Koizumi wrote:
The attached patch may be a fix for that bug.
Hope it works.
Moriyoshi
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
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
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)
The new appears to work correctly and previously mentioned problem no longer
occures. I've also ran the test suit after applying the patch and none of the
tests have been adversly affected, so it does not appear to break any old
functionality.
Ilia
On November 5, 2002 09:17 pm, Moriyoshi Koizumi wrote:
Perhaps my patch was not sufficient... A revised patch is attached. Please
try this one, and if you like the patch, then commit it with extreme care
:)
Moriyoshi
On November 5, 2002 05:48 pm, Moriyoshi Koizumi wrote:
The attached patch may be a fix for that bug.
Hope it works.
Moriyoshi
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
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
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)
On November 5, 2002 09:44 pm, Moriyoshi Koizumi wrote:
Ilia, thank you for double-checking.
Since I have no access to Zend module, I'm waiting for that to be
committed by someone for now... Does it need more review?
It would probably be a good idea if more developers review this patch before
it goes in. If there won't be any objections to the patch, I will commit it
on your behalf.
Ilia
Moriyoshi
Ilia A. [EMAIL PROTECTED] wrote:
The new appears to work correctly and previously mentioned problem no
longer occures. I've also ran the test suit after applying the patch and
none of the tests have been adversly affected, so it does not appear to
break any old functionality.
Ilia
On November 5, 2002 09:17 pm, Moriyoshi Koizumi wrote:
Perhaps my patch was not sufficient... A revised patch is attached.
Please try this one, and if you like the patch, then commit it with
extreme care
:)
Moriyoshi
On November 5, 2002 05:48 pm, Moriyoshi Koizumi wrote:
The attached patch may be a fix for that bug.
Hope it works.
Moriyoshi
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
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
--
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: [PATCH] run-tests.php
On November 1, 2002 10:05 am, Melvyn Sopacua wrote:
At 15:37 1-11-2002, Derick Rethans wrote:
Any objections?
We can't object if there is no attachment :)
?php while($i100) { echo substr('#*!$%', mt_rand(1,6), 1); $i++; } ?
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
Looks fine to me, +1.
Ilia
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] run-tests.php
On November 1, 2002 12:23 pm, John Coggeshall wrote: Wait wait wait.. I think I've been misunderstood... I'm not talking about the version 4.3 release, and yes we are working on the web edition of the test script.. However, Shane (rightly so, IMHO) re-wrote run-tests (now run-tests2) and made it a class (testHarness) from which to base the web-based testing from... What made you decide to go for the OO model of the run-tests script, there does not seem to be any advantage in adding this overhead (imho)? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] run-tests.php
On November 1, 2002 01:08 pm, John Coggeshall wrote:
|What made you decide to go for the OO model of the run-tests
|script, there
|does not seem to be any advantage in adding this overhead (imho)?
There is most definitely an advantage. Using the OO model, we
essentially created
A test engine which had some default output code (direct to stdout)
and ran all of
The desired tests... It basically runs just like the current
run-tests.php script (maybe
Not as many pretty colors, etc).
The reason the OO is cool though, is when we want to port that test
script into another
Medium or output it in a different format such as HTML. I just created a
new object which
Extended the base class and overload some of the functions (such as
showstatus() which is
Called every time a test passes/fails) to generate HTML output instead
of text..
In the most basic form testing process consists of 4 parts. Executing the
script, parsing output, comparing the output to the expected output and
comparing the results.
Ideally (imho) the process would look something like this pseudo code:
function execute_test(test, MODE)
{
$test_data = init_test(test);
$result = run_test(test_script, MODE);
$test_output = fetch_test_output($result, MODE);
$bool_status = compare_output($test_output, $test_data['expected_output']);
return_output($bool_status, $test_data, $test_output, MODE);
}
The MODE would indicate the mode of operation (cli/cgi/webserver and so on),
each step where the MODE is relevant would then have a switch to determine
which function should be executed at this point. So, if MODE is cli, we'd run
cli_run_test() and similarly if the MODE is web, we'd run web_run_test().
This would make a simpler test, which would not need to rely on more advanced
features like OO, which may change in their functionality once ZE2 comes
around, as Marcus had pointed out. Since at this point we could have people
running both ZE1 and ZE2 use the test, I think relying on OO is dangerous.
My reasoning is that considering the simplicity of the testing 'engine', we do
not need to add the OO layer of obfuscation. Now, I am not a big fan of OO,
so my opinion on the matter maybe somewhat skewed in that regard, non
Ilia
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] ereg to pcre conversion
Currently PHP ships with two regular expression libraries that are both
installed by default, PCRE regex. The regex library that is responsible for
ereg_* functions is fairly old and offers a very limited functionality
compared to the PCRE library. In most cases the PCRE functions are also much
faster then the old ereg functions.
I would like to propose that we drop the old ereg library and use only
a single regular expression library, PCRE. For BC purposes I've written a
patch (see attached file), which emulates the old ereg_* functions for people
who still rely on those, using PCRE.
This cleanup would mean we'd only need to maintain one set of regular
expression code, which as far as code goes is pretty complex as well as give
speed-up for people still using ereg.
Perhaps, at some future point this would allow us to drop the ereg_* functions
all together.
Ilia
Index: pcre/php_pcre.c
===
RCS file: /repository/php4/ext/pcre/php_pcre.c,v
retrieving revision 1.130
diff -u -3 -p -r1.130 php_pcre.c
--- pcre/php_pcre.c 24 Oct 2002 19:06:19 - 1.130
+++ pcre/php_pcre.c 31 Oct 2002 13:57:58 -
-553,6 +553,110 static void php_pcre_match(INTERNAL_FUNC
}
/* }}} */
+/* {{{ ereg_to_pcre_convert
+*/
+static inline zval *ereg_to_pcre_convert(zval **reg_expr, int case_sens)
+{
+ char *p, *pp;
+ int extra_len = 3;
+ zval *new_reg;
+
+ if (case_sens) {
+ extra_len++;
+ }
+
+ MAKE_STD_ZVAL(new_reg);
+
+ Z_STRVAL_P(new_reg) = emalloc(Z_STRLEN_PP(reg_expr) * 2 + extra_len + 1);
+ Z_TYPE_P(new_reg) = IS_STRING;
+
+ pp = Z_STRVAL_PP(reg_expr);
+ p = Z_STRVAL_P(new_reg);
+
+ *p++ = '/';
+ while (*pp) {
+ if (*pp != '/') {
+ *p++ = *pp;
+ } else {
+ *p++ = '\\';
+ *p++ = '/';
+ extra_len++;
+ }
+ pp++;
+ }
+
+ *p++ = '/';
+ if (case_sens) {
+ *p++ = 'i';
+ }
+ *p++ = 's';
+ *p = '\0';
+
+ Z_STRLEN_P(new_reg) = Z_STRLEN_PP(reg_expr) + extra_len;
+
+ return new_reg;
+}
+/* }}} */
+
+/* {{{ php_pcre_ereg_match
+*/
+static void php_pcre_ereg_match(INTERNAL_FUNCTION_PARAMETERS, int case_sens)
+{
+ zval **old_regex, **m_string, **subpats = NULL;
+ zval **args[3];
+ zval *retval, *pcre_func, *new_regx;
+
+ int argc = ZEND_NUM_ARGS();
+
+ if ((argc != 2 argc != 3) || (zend_get_parameters_ex(argc, old_regex,
+m_string, subpats) == FAILURE)) {
+ WRONG_PARAM_COUNT;
+ }
+
+ MAKE_STD_ZVAL(pcre_func);
+ ZVAL_STRING(pcre_func, preg_match, 1);
+
+ convert_to_string_ex(old_regex);
+
+ new_regx = ereg_to_pcre_convert(old_regex, case_sens);
+
+ args[0] = new_regx;
+ args[1] = m_string;
+ args[2] = subpats;
+
+ if (call_user_function_ex(EG(function_table), NULL, pcre_func, retval, argc,
+args, 0, NULL TSRMLS_CC) == SUCCESS) {
+ if (Z_LVAL_P(retval)) {
+ RETVAL_TRUE;
+ } else {
+ RETVAL_FALSE;
+ }
+ } else {
+ RETVAL_FALSE;
+ }
+
+ zval_dtor(new_regx);
+ FREE_ZVAL(new_regx);
+ zval_dtor(pcre_func);
+ FREE_ZVAL(pcre_func);
+ FREE_ZVAL(retval);
+}
+/* }}} */
+
+/* {{{ proto int ereg(string pattern, string string [, array registers])
+ Regular expression match */
+PHP_FUNCTION(ereg)
+{
+ php_pcre_ereg_match(INTERNAL_FUNCTION_PARAM_PASSTHRU, 0);
+}
+/* }}} */
+
+/* {{{ proto int eregi(string pattern, string string [, array registers])
+ Case-insensitive regular expression match */
+PHP_FUNCTION(eregi)
+{
+ php_pcre_ereg_match(INTERNAL_FUNCTION_PARAM_PASSTHRU, 1);
+}
+/* }}} */
+
/* {{{ proto int preg_match(string pattern, string subject [, array subpatterns [,
int flags]])
Perform a Perl-style regular expression match */
PHP_FUNCTION(preg_match)
-1102,6 +1206,62 static void preg_replace_impl(INTERNAL_F
}
/* }}} */
+/* {{{ php_pcre_ereg_replace
+*/
+static void php_pcre_ereg_replace(INTERNAL_FUNCTION_PARAMETERS, int case_sens)
+{
+ zval **old_regex, **repl, **src_str;
+ zval **args[3];
+ zval *retval, *pcre_func, *new_regx;
+
+ int argc = ZEND_NUM_ARGS();
+
+ if (argc != 3 || (zend_get_parameters_ex(argc, old_regex, repl, src_str) ==
+FAILURE)) {
+ WRONG_PARAM_COUNT;
+ }
+
+ MAKE_STD_ZVAL(pcre_func);
+ ZVAL_STRING(pcre_func, preg_replace, 1);
+
+ convert_to_string_ex(old_regex);
+
+ new_regx = ereg_to_pcre_convert(old_regex, case_sens);
+
+ args[0] = new_regx;
+ args[1] = repl;
+ args[2
Re: [PHP-DEV] [PATCH] ereg to pcre conversion
On October 31, 2002 02:57 pm, Adam Maccabee Trachtenberg wrote: So you're planning on converting POSIX regexen to PCRE so people don't need to worry about PCRE metacharacters that are POSIX literals? Seems tricky. (e.g. is \w a backslash and a w or a word character? what about search patterns of 10 instead of 10 they have different meanings in egrep(), you'll need to convert this, too.) I believe this patch already has protection against such problem. In the event it does not, I'd be happy to make the necessary changes to the patch, so that the old ereg_* behaviour can be maintained. Ilia -adam On Thu, 31 Oct 2002, Ilia A. wrote: Currently PHP ships with two regular expression libraries that are both installed by default, PCRE regex. The regex library that is responsible for ereg_* functions is fairly old and offers a very limited functionality compared to the PCRE library. In most cases the PCRE functions are also much faster then the old ereg functions. I would like to propose that we drop the old ereg library and use only a single regular expression library, PCRE. For BC purposes I've written a patch (see attached file), which emulates the old ereg_* functions for people who still rely on those, using PCRE. This cleanup would mean we'd only need to maintain one set of regular expression code, which as far as code goes is pretty complex as well as give speed-up for people still using ereg. Perhaps, at some future point this would allow us to drop the ereg_* functions all together. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] ereg to pcre conversion
On October 31, 2002 03:12 pm, Ori Staub wrote: A few tests using eregi on windows and linux shows that it can be up to 30 times faster the PCRE for some expressions (e.g. validating email address format). See an interesting thread on sitepoint ( http://www.sitepointforums.com/showthread.php?s=threadid=71134 ) with some sample benchmark scripts. That test was flawed, preg_* style regular expressions became the leaders once the regex was fixed. After then according to people's reports it was 4+ times faster then eregi. Ilia Ori - Original Message - From: Ilia A. [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 12:47 PM Subject: [PHP-DEV] [PATCH] ereg to pcre conversion Currently PHP ships with two regular expression libraries that are both installed by default, PCRE regex. The regex library that is responsible for ereg_* functions is fairly old and offers a very limited functionality compared to the PCRE library. In most cases the PCRE functions are also much faster then the old ereg functions. I would like to propose that we drop the old ereg library and use only a single regular expression library, PCRE. For BC purposes I've written a patch (see attached file), which emulates the old ereg_* functions for people who still rely on those, using PCRE. This cleanup would mean we'd only need to maintain one set of regular expression code, which as far as code goes is pretty complex as well as give speed-up for people still using ereg. Perhaps, at some future point this would allow us to drop the ereg_* functions all together. 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-DEV] safe_mode_include_dir option
The current implementation of the safe_mode_include_dir only allows bypassing of safe_mode by the include/require functions in the specified directories. No other safe_mode limited file operation can access those files. Since there is no other parameter other then safe_mode_include_dir to 'unlock' a directory while in safe_mode, perhaps we should allow other filesystem functions to operate on files/directories specified inside safe_mode_include_dir ? Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: run-tests.php errors/warnings
On October 29, 2002 09:52 am, Marcus Boerger wrote: I think we need to discuss the behaviour of run-tests.php according too error/warning handling a bit. First question (let me know if i am wrong): Any error/warning/ notice in a test result is either expected or a real error. Agreed, however in 99% of the cases the data which is being outputted is what matters. As long as it is the same data as the one we expect, all the warnings/notices are irrelevant, imho. That said, ideally the tests should not cause warnings/notices, unless of course, the purpose of the test is to see if a warning/notice message will be generated. In the event a needed warning is generated, the track_errors $php_errormsg facility should be used to display the error (we already enable tracking of errors by default). Adding to block the errors is not a good approach imho, the warning should be displayed and accounted for in the expected output. Remark 1: auto_append_file= auto_prepend_file= currently do not work but that is another thread. Seems to work just fine here. Remark 2: We could instead use the log_errors and direct them to the output with the following changes to above settings: display_errors=0 log_errors=1 The output would be nicer but when we go to test other sapis than CGI/CLI this won't work anymore. The tests can only be performed using the cgi/cli sapis since they require a command line PHP binary. So, this is a non-issue. If we must display error messages then I would prefer using display_errors=1 instead of log_errors=1. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] I hope this is the last email about this :)
+1 to keep PHP-CLI with implicit_flush. Ilia On October 27, 2002 09:05 pm, Zeev Suraski wrote: Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. You vote against. Can we get some other votes now (not opinions, everything was already said a dozen times, just votes to get this over with). Thanks! Zeev At 15:11 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: At 09:15 25/10/2002, Yasuo Ohgaki wrote: Zeev Suraski wrote: You print something, it doesn't print out. How is it trivial to solve this? If you happen to know that there's IO buffering and that there's a function called flush() then maybe it trivial, but then there are the other million users who don't. Hence the idea of setting is to implicit flush for the masses, who not only don't know about the existence of flush(), but also don't know why it's even necessary. Ok. If we are argue about what is mass or not Don't forget about - millions(?) of _current_ PHP users who are used to implicit_flush=off by default. Few of them use CLI. As I mentioned already, people are used to implicit_off=off and it's the default of other SAPIs, therefore, it's not intuitive for existing users. If we aren't care about much about existing users base, I think we should set short_tag=Off by default, but you're insisting it should be on even if much fewer people are using. I'm confused. People expects PHP/CLI behave like Apache SAPI, CGI SAPI, etc. Well, if I weren't developer and didn't know discussion, I'll certainly write bug report that implicit flush is enabled wrongly. - millions of decent programmers who are used to _usual_ behavior. I consider myself a decent programmer, and I also consider the need to flush explicitly extremely annoying. Moreover, many PHP programmers (if not most) aren't used to this 'usual' behavior, because they either never programmed in another language, or they still didn't bump into that specific behavior. Don't you think flushing is needed only very limited applications? i.e. We don't write interactive CUI applications much now a days. - millions of scripts/echo/print don't need automatic flush at all. i.e. much fewer number of script/echo/print need auto flushing. It doesn't matter. When you're screwed by the lack of implicit flush, it's much worse than a mere slow down. Hmm. Since console is line buffered. There aren't many thing that is missed by implicit flushing. Please list programming languages (i.e. not shell) that do automatic/inefficient/unneeded flushing by default in program mode. Read my fingertips - PHP IN CLI MODE. There's one, that's the only one I care about. My point is we should learn from many smart peoples designs' of languages. If we are argue about difficulty of flushing, We're not. We're arguing about the obscurity of the problem. implicit_flush=On is obscure for current users. Suppose not flushing is extremely obscure, but default is better to set which is better/suitable for more occasions and is better to be consistent with other SAPIs. Is this the main point of auto flushing? If there are other points, please list them. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php
I am curios as to your reasoning behind turning on html_errors by default, why
would the tests need HTML data?
Logging of errors occurred during the tests seems pointless to me. As I've
mentioned before if a test needs to check if a certain type of error is
generated the track_errors $php_errormsg facility can be used to capture
this error reliably. Logging of errors is unreliable since the actual error
message can go anywhere, stderr,syslog, user specified file, etc... It is
highly likely that you may not even see the error message because it is not
sent to stderr. Data sent to the error log is also 'variable', because it
contains fluid data which different from system to system due to file paths,
so we must do all kinds of hackery if we are to use it when confirming the
output of a test.
I for one, would like to see that setting go away.
Ilia
P.S. The recent change to ini settings broken 9 tests, which worked fine prior
to your change.
EUC-JP to ISO-2022-JP [ext/iconv/tests/eucjp2iso2022jp.phpt]
EUC-JP to SJIS [ext/iconv/tests/eucjp2sjis.phpt]
EUC-JP to UTF8 [ext/iconv/tests/eucjp2utf8.phpt]
iconv test [ext/iconv/tests/iconv001.phpt]
UCS4BE to ASCII [ext/iconv/tests/iconv002.phpt]
ob_output_handler [ext/iconv/tests/ob_iconv_handler.phpt]
HTML input/output [ext/mbstring/tests/htmlent.phpt]
rewriter handles form and fieldset correctly [ext/session/tests/021.phpt]
Memoryleak in error printing [ext/xslt/tests/xslt-001.phpt]
On October 27, 2002 07:14 pm, Marcus Börger wrote:
First the tests take the nomal ini settings from any file found by php...
Second there are some settings overwritten by run-test.php..
Third you can overwrite first and second by specifying an INI section in
the .phpt files.
Now to the setting log_errors i want this thing on because ANY
MESSAGE is either wanted or a REAL ERROR. The only test being
an exception to this rule is ext/session/tests/008-php4.2.3.phpt.
This test requires log_error to be set 0.
BEFORE REMOVING log_errors=1 again i want this beeing
discussed!
marcus
At 01:07 28.10.2002, Marcus Börger wrote:
helly Sun Oct 27 19:07:11 2002 EDT
Modified files:
/php4 run-tests.php
Log:
allow default ini overwrites to be overwritten themselves in --INI--
#see followup on dev list
Index: php4/run-tests.php
diff -u php4/run-tests.php:1.91 php4/run-tests.php:1.92
--- php4/run-tests.php:1.91 Sat Oct 26 12:54:30 2002
+++ php4/run-tests.php Sun Oct 27 19:07:11 2002
-480,28 +480,50
// Default ini settings
$settings = array (
- -d 'open_basedir=',
- -d 'disable_functions=',
- -d 'error_reporting=2047',
- -d 'display_errors=0',
- -d 'log_errors=0',
- -d 'html_errors=0',
- -d 'docref_root=/phpmanual/',
- -d 'docref_ext=.html',
- -d 'error_prepend_string=',
- -d 'error_append_string=',
- -d 'auto_append_file=',
- -d 'auto_prepend_file=',
+ open_basedir=,
+ disable_functions=,
+ error_reporting=2047,
+ display_errors=0,
+ log_errors=1,
+ html_errors=1,
+ track_errors=1,
+ docref_root=/phpmanual/,
+ docref_ext=.html,
+ error_prepend_string=,
+ error_append_string=,
+ auto_append_file=,
+ auto_prepend_file=,
);
- $ini_settings = ' '. join (' ', $settings);
+ $ini_settings = array();
+ foreach($settings as $setting) {
+ if (strpos($setting, '=')!==false) {
+ $setting = explode(=, $setting);
+ $name = trim(strtolower($setting[0]));
+ $value = trim($setting[1]);
+ $ini_settings[$name] = $value;
+ }
+ }
- // Any special ini settings
+ // Any special ini settings
+ // these may overwrite the test defaults...
if (array_key_exists('INI', $section_text)) {
foreach(preg_split( /[\n\r]+/, $section_text['INI']) as
$setting) {
- if (strlen($setting)) {
- $ini_settings .= -d '$setting';
+ if (strpos($setting, '=')!==false) {
+ $setting = explode(=, $setting);
+ $name = trim(strtolower($setting[0]));
+ $value = trim($setting[1]);
+ $ini_settings[$name] = $value;
}
}
+ }
+ if (count($ini_settings)) {
+ $settings = '';
+ foreach($ini_settings as $name = $value) {
+ $settings .= -d '$name=$value
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php
On October 25, 2002 04:01 pm, Marcus Börger wrote: I haven't installed xslt yet so i do not know...but i am testing with 25% of the modules and get the feeling that we must check for all warnings and errors. A special situation is ext/session/tests/008-php4.2.3.phpt where a warning mechanism is checked..here the following would be enough --EXPECTF-- %s(%d) : Warning - Your %s But perhaps it would be a better solution to automatically add ?php echo $error_msg; ? at the end of each FILE section and set track_errors=1, display_errors=0, log_errors=0. That test was already slightly reworked (error reporting portion of the script) to do almost exactly that. The echoing of the error variable cannot be done at the end of the script, because if there are any other errors and/or warnings they would overwrite the value stored inside the variable. So, it needs to be printed as soon as the error occures. Ilia At 21:41 25.10.2002, Melvyn Sopacua wrote: At 21:27 25-10-2002, Marcus Börger wrote: It should not break any test...please send a list of those failed. ext/xslt/xslt-001.phpt (used to be 009.phpt). log_errors=1 on cli, is /dev/stderr. Ilia: Could you take a look at the message I sent regarding your fix of that test? There are other problems with memory leaks (display_memleak and --disable-debug), so I'm enclined to drop this test - the format of the error message is not important and not what we we're testing. I've wrapped the procedure that caused the memleak in the first place into a macro, and used that. Any future places this should occur, we'll use the macro. marcus At 19:24 25.10.2002, Ilia Alshanetsky wrote: iliaa Fri Oct 25 13:24:10 2002 EDT Modified files: /php4 run-tests.php Log: The log_errors=1 breaks a number of tests and is useless for our purposes, removing. Index: php4/run-tests.php diff -u php4/run-tests.php:1.89 php4/run-tests.php:1.90 --- php4/run-tests.php:1.89 Thu Oct 24 14:14:39 2002 +++ php4/run-tests.php Fri Oct 25 13:24:09 2002 -484,7 +484,7 -d 'disable_functions=', -d 'error_reporting=2047', -d 'display_errors=0', - -d 'log_errors=1', + -d 'log_errors=0', -d 'html_errors=0', -d 'docref_root=/phpmanual/', -d 'docref_ext=.html', -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Met vriendelijke groeten / With kind regards, Webmaster IDG.nl Melvyn Sopacua -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Regex Libraries
Currently PHP contains two bundled regular expression libraries, PECL and regex. I am wondering if it would be a good idea to drop the old regex (dates back to 1999) library and use only PECL. The advantage is performance, cleaner code and a more flexible and more recent library. For the people who still use ereg functions, we could create wrappers that would implement their functionality using PECL and possibly add an E_NOTICE indicating that using PECL function preg_* would be a better approach. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [4.3] Current critical bugs
On October 17, 2002 07:06 pm, Yasuo Ohgaki wrote: Andrei Zmievski wrote: Hi, We have 10 critical bugs in the list currently. If you could please see about fixing at least one of them, we'd be that much closer to a release candidate. Summary: Apache2 sending 304 - not modified header http://bugs.php.net/bug.php?id=17098 This is serious problem for serious sites. (Serious sites shouldn't use Apache2, though) This looks like an Apache 2 bug, rather then aPHP one. I am guessing the fix they made did not work properly. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] parse_url still broken!
Also fixed.
Ilia
On October 18, 2002 06:37 am, Thies C. Arntzen wrote:
url:
file:/bla/test
4.2.x output:
array(2) {
[scheme]=
string(4) file
[path]=
string(9) /bla/test
}
HEAD:
array(3) {
[scheme]=
string(4) file
[host]=
string(3) bla
[path]=
string(5) /test
}
re,
tc
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Since the general consensus by the developers is not to remove the short_tags
or even disable them. Perhaps we should consider alternate solutions to this
problem. Given the buzzword popularity of XML and its slowly growing
popularity among website designers (XHTML) this issue is likely to come up in
the future yet again.
The solution I would like to offer, is a patch that adds special handling for
?xml. Thus preventing the language parser from attempting to parse data
inside ?xml as PHP source.
Ilia
Index: zend_language_scanner.l
===
RCS file: /repository/Zend/zend_language_scanner.l,v
retrieving revision 1.49
diff -u -3 -p -r1.49 zend_language_scanner.l
--- zend_language_scanner.l 15 Aug 2002 00:22:38 - 1.49
+++ zend_language_scanner.l 16 Oct 2002 16:07:27 -
-1194,6 +1194,14 NEWLINE (\r|\n|\r\n)
}
+INITIAL?xml{WHITESPACE} {
+ zendlval-value.str.val = (char *) estrndup(yytext, yyleng);
+ zendlval-value.str.len = yyleng;
+ zendlval-type = IS_STRING;
+ return T_INLINE_HTML;
+}
+
+
INITIAL%=|?= {
if ((yytext[1]=='%' CG(asp_tags)) || (yytext[1]=='?' CG(short_tags))) {
zendlval-value.str.val = yytext; /* no copying - intentional */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On October 16, 2002 10:18 pm, Yasuo Ohgaki wrote: Ilia A. wrote: Since the general consensus by the developers is not to remove the short_tags or even disable them. Perhaps we should consider alternate solutions to this problem. Given the buzzword popularity of XML and its slowly growing popularity among website designers (XHTML) this issue is likely to come up in the future yet again. The solution I would like to offer, is a patch that adds special handling for ?xml. Thus preventing the language parser from attempting to parse data inside ?xml as PHP source. I think it's reasonable patch, but ? is XML Processing Instruction tag... We never know how many processing tags will be in the future. We don't know if there will be xml processor that processes php tag or not. Therefore, user should turn short tag off by themselves if the want to use XML, or echo ?xml .. at the beginning of output. Yes sure, but as these discussions, which are starting to appear with ever increasing frequency that is simply not the case. There are numerous reasons for this many of which have been covered in various discussion on this topic. IMO, disabling short tag in php.ini-recommended is ok in the future. I know Zeev don't like it and I understand the reasoning. :) Maybe I am wrong, but judging from the feedback given by various developers this is unlikely to happen even in PHP 5.0. Thus, I think we must consider how to address this problem via other means. Unless we can solve this issue, then we return to this discussion again and again. Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On October 16, 2002 11:11 pm, Yasuo Ohgaki wrote: Ilia A. wrote: Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. We should have warned people not to use short tags years ago. What happened in the past is in the past, lets concentrate on the future. We can try it from now. Until we get rid of short tag or disable it by default, we suggest users to work around problem. echo ?xml ..? works always and authors of portable scripts should use it. If there are new processing tags, echo ?new_xml_PI .? instead of adding new PI to parser. (We never know if user use custom PI tag or not) I think that we can say with a fair degree of certainty ?xml will remain as is. No one will want to change for BC reasons ;). I find it even less likely that we'd drop short tags when PHP6 comes around because they'll be even more users using them then there are now (assuming php usage increases). For most people it is easier to use ? then ?php and since it works just about everywhere it is 'safe' to do, at least as far as they know. It is also to easier to remember, especially for newbies, which imho is the most common reasons people use them. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On October 16, 2002 11:46 pm, Yasuo Ohgaki wrote: We had the same discussion. I brought it up last time. There were patch for ?xml just like yours. The outcome was modified manual page that discourages use of short tag for portable script. http://www.php.net/manual/en/language.basic-syntax.php Given the fact we are carrying this conversation again, implies the original solution did not solve the problem, no? Current php.ini-dist has ==but what about all the people who for whatever reason make their PHP parse all pages, even .html ones ; Allow the ? tag. Otherwise, only ?php and script tags are recognized. short_open_tag = On == Adding appropriate comment is better than adding token to language. i.e. compatibility between new and old PHP. I am not saying that the proposed patch is the best solution to the problem, there may very well be other, better solutions. However, I personally, do not see such solutions being presented. All the solutions either involve breaking of BC, which most people do not wish to do, or ignoring the issue and hoping that eventually people will switch. The best way to go is discourage use of short tag whenever possible, change default few years later, IMHO. Even if we never change the default, ?php echo ?xml ..?;? works always w/o patch. Yes, that works, but what about all the people who for whatever reason make their PHP parse all pages, even .html ones. On such a server if someone places an XML (XHTML) document, won't they be surprised by the parse errors they get. This person may not even know PHP exists and yet they would get PHP errors. No amount of documentation will solve this sort of a problem and this is just one example, there are more. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Streams Problems
After further testing, specifically the latest run-tests.php script, it appears that sending data via sockets using php is still problematic. Using the latest CVS I've tried sending a string 60960 bytes long via HTTP (POST request). According to another PHP script on the other end only 60415 bytes of data actually arrived. This leads me to believe that the problem is still there, albeit there is some improvment from before, when anything in excess of 16k got cut off. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
