Re: [PHP-DEV] Fix for wordwrap()

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Apache2 SAPI

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] imagesavealpha()

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] #php.bugs invite only?

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/tokenizer tokenizer.c

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CLI & long options

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Apache 2.0 Handler module

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: str_ireplace vs. stri_replace

[Ilia A.]

> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: str_ireplace vs. stri_replace

[Ilia A.]

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 _. 
> > 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

[Ilia A.]

> Well, actually, I would prefer to see a proper BNDM
> implementation in the tree.
>
> - character classes are handled for free
>   (i.e. a case insensitive search does not take longer)
>
> - combining shift-and and automata is much faster than our
>   current naive algorithm (I may say so, I wrote it years ago)
>
> - allows us to combine multiple patterns into one search (I
>   have not studied that part of the paper yet). This would
>   enable us to optimize the case where you pass arrays to
>   str_replace.  Instead of scanning the "haystack" one time
>   per replacement text, we would scan it only once.

Even if the compiling step of the BNDM were to be cached (like the compiled 
pcre regex) in many cases it would still be slower then php_memnstr(). I've 
run a series of tests using a simple BNDM implementation (roughly based on 
your original) and while it is faster in some cases in many cases it is not. 
When the search string is short (<=5 characters) or when it is found near the 
start of the input string regular memnstr search often proves to be faster 
often by fairly significant margin. For refenrece sake I am attaching my BNDM 
& php_memnstr() test sources that I've used.

Ilia
#include 
#include 

#define NED "Dynamic_DBnested.sql"
#define STR "cvs: pear /Tree/docs Dynamic_DBnested.php Dynamic_DBnested.sql 
Memory_DBnested.php Memory_DBsimple.php Memory_XML.php config.xml 
/Tree/docs/TreeEditor config.xml index.php index.tpl mysql_db.sql treeClass.php 
/Tree/docs/TreeEditor/tmp .htaccess /Tree/docs/TreeView index.php index.tpl 
/Tree/docs/TreeView/tmp .htaccess"

/*
 * BNDM algorithm implementation
 * based on sample code by Sascha Schumann 
(http://www.mail-archive.com/dev@httpd.apache.org/msg00939.html)
 */

typedef struct {
unsigned int T[256];
unsigned int x;
} bndm_t;

inline static void bndm_compile(bndm_t *t, char *str, int str_len)
{
size_t p;
register unsigned int s = 1;

t->x = 1 << (str_len-1);
memset(t->T, 0, sizeof(unsigned int) * 256);
  
for (p = str_len - 1; p > 0; p--) { 
t->T[(int) str[p]] |= s;
s <<= 1;
}
t->T[(int) str[p]] |= s;

return;
}

static inline char *bndm (char *haystack, int haystack_len, char *needle, int 
needle_len, bndm_t *t)
{
size_t p, j, e;
register unsigned int b;

p = 0;
while (p + needle_len <= haystack_len) {
b = -1;
e = needle_len;
j = needle_len - 1;
do {
if ((b &= t->T[ haystack[p + j] ]) == 0) {
break;
}
if ((b & t->x) != 0) {
if (j == 0) {
return (haystack + p);
}
e = j;
}
j--;
b <<= 1;
} while (b != 0);
p += e;
}

return NULL;
}

int main()
{
int n = 500;
char *d;
bndm_t foo;

bndm_compile(&foo, NED, sizeof(NED)-1);
 
while (n--) {
if (!(d = bndm(STR, sizeof(STR)-1, NED, sizeof(NED)-1, &foo))) {
break;
}
}
printf("matched on: %s\n", d);
 
return 0;
}

#include 
#include 

#define PAT "Dynamic_DBnested.sql"
#define STR "cvs: pear /Tree/docs Dynamic_DBnested.php Dynamic_DBnested.sql 
Memory_DBnested.php Memory_DBsimple.php Memory_XML.php config.xml 
/Tree/docs/TreeEditor config.xml index.php index.tpl mysql_db.sql treeClass.php 
/Tree/docs/TreeEditor/tmp .htaccess /Tree/docs/TreeView index.php index.tpl 
/Tree/docs/TreeView/tmp .htaccess"

static inline char *php_memnstr(char *haystack, char *needle, int needle_len, char 
*end)
{
char *p = haystack;
char ne = needle[needle_len-1];

end -= needle_len;

while (p <= end) {
if ((p = memchr(p, *needle, (end-p+1))) && ne == p[needle_len-1]) {
if (!memcmp(needle, p, needle_len-1)) {
return p;
}
}

if (p == NULL) {
return NULL;
}

p++;
}

return NULL;
}

int main()
{
int n = 500;
char *d;
 
while (n--) {
if (!(d = php_memnstr(STR, PAT, sizeof(PAT)-1, STR + sizeof(STR)-1))) {
break;
}
}
printf("matched on: %s\n", d);
  

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

[Ilia A.]

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
 $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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()

[Ilia A.]

> 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 
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

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Error from last cvs (php4)

[Ilia A.]

The error occurs because you are trying to compile HEAD (which is php5, based 
on ZE2) with ZE1, hence certain defined constants are not avaliable. To 
checkout head use 'php5' tag, that will get you latest PHP sources + ZE2.

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Adding to the bundled GDlib

[Ilia A.]

On January 25, 2003 01:40 pm, Kasper Skårhøj wrote:
> But my actual request is this:
> - Who is in charge of the bundled GD? (Who can I discuss it with)

There are a number of people who had contributed their wonderful work to PHP's 
GD extension and the bundled GD library. As far as active maintainers that 
works at the moment is done by me and Pierre-Alain Joye.

> - What is the policy on that library? Do you want it to be expanded with
> new functions? - Would you be positive towards additions from me? (I want
> to know this before I spend more brainpower) - How can I help? (I'm new to
> this list but is a very experienced PHP programmer since PHP/FI 2)

Well, you can begin by sending a patch to the list, which would give everyone 
a chance to see and make comments. If there is no opposition to your addition 
then someone can commit the patch on your behalf or if you intend to make 
future contributions to PHP's GD you can request a CVS account.

Ilia

-- 
PHP Development Mailing List 
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

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] string functions

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] UNIX file command

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Patch for #21309 - memory + php_error_docref.

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] Merging into PHP_4_3

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Proposed fix for bug #21149

[Ilia A.]

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 
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

[Ilia A.]

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

Re: [PHP-DEV] Re: #21060 [Opn->Bgs]: range() gives warning and returns false when low == high

[Ilia A.]

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

[PHP-DEV] Re: #21060 [Opn->Bgs]: range() gives warning and returns false when low == high

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[Ilia A.]

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] Re: #20972 [Opn->Csd]: make fails during gd.c

[Ilia A.]

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_LIB

Re: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[Ilia A.]

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=20972&edit=1


-- 
PHP Development Mailing List 
To unsubscr

Re: [PHP-DEV] register_shutdown_function => register_offline_function

[Ilia A.]

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 
> | > 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New SNMP function names

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Ilia A.]

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 
> > To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Redirect on Error (not localisation)

[Ilia A.]

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 
> >To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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] [PATCH] Redirect on Error

[Ilia A.]

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

[Ilia A.]

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] Error Codes, Langs, etc

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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

[Ilia A.]

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-3

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Redirect on Error

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Build of bundled GD broken on Win32

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] GD segfault in 4.3.0RC1

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mime_magic segfaults

[Ilia A.]

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 , 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

[Ilia A.]

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 , 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

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

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

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

[Ilia A.]

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

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mbstring and 4.3.0

[Ilia A.]

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

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Snaps

[Ilia A.]

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

Re: [PHP-DEV] PHP Snaps

[Ilia A.]

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

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] PHP Snaps

[Ilia A.]

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 
> > >To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > --
> > PHP Quality Assurance Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Configuration Patches

[Ilia A.]

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 
+#endif
+
 /* AIX requires this to be the first thing in the file.  */
 #ifndef __GNUC__
-# if HAVE_ALLOCA_H
-#  include 
-# 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Please help document headers_sent()

[Ilia A.]

On November 6, 2002 07:10 pm, Philip Olson wrote:
> I get a Segmentation fault with this script using
> PHP CLI:
>
>  headers_sent($file, $line);
> ?>
>   philip@rock:~$ 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

>  print "foo\n";
> headers_sent($file, $line);
> print "$file : $line\n";
> ?>
>   philip@rock:~$ 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 
> > To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

[Ilia A.]

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.
> > > > > >
> > > > > > ---
> > > > > >  > > > > > $ragged = array();
> > > > > > $ragged[0] = "a";
> > > > > > $ragged[0][0] = array("1");
> > > > > > var_dump($ragged);
> > > > > > ?>
> > > > > > ---
> > > > > >
> > > > > > The first script causes no leaks, while the second does:
> > > > > > ---
> > > > > >  > > > > > $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.
> > > > > > > >
> > > > > > > > -
> > > > > > > >--  > > > > > > > $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", $

Re: [PHP-DEV] [PATCH] A suggested fix for bug #19943 (Re: [PHP-DEV] bug #19943)

[Ilia A.]

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.
> > > >
> > > > ---
> > > >  > > > $ragged = array();
> > > > $ragged[0] = "a";
> > > > $ragged[0][0] = array("1");
> > > > var_dump($ragged);
> > > > ?>
> > > > ---
> > > >
> > > > The first script causes no leaks, while the second does:
> > > > ---
> > > >  > > > $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.
> > > > > >
> > > > > > ---
> > > > > >  > > > > > $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:
> > > > > > ---
> > > > > >  > > > > > $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)

[Ilia A.]

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:


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.
> >
> > ---
> >  > $ragged = array();
> > $ragged[0] = "a";
> > $ragged[0][0] = array("1");
> > var_dump($ragged);
> > ?>
> > ---
> >
> > The first script causes no leaks, while the second does:
> > -------
> >  > $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.
> > > >
> > > > ---
> > > >  > > > $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:
> > > > ---
> > > >  > > > $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] bug #19943

[Ilia A.]

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.
>
> ---
>  $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:
> ---
>  $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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Win32 snaps ext/xslt

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PATCH] run-tests.php

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PATCH] run-tests.php

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PATCH] run-tests.php

[Ilia A.]

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 :)
>
> #*!$%', mt_rand(1,6), 1); $i++; } ?>
>
>
> With kind regards,
>
> Melvyn Sopacua
> 

Looks fine to me, +1.

Ilia

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] ereg to pcre conversion

[Ilia A.]

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

Re: [PHP-DEV] [PATCH] ereg to pcre conversion

[Ilia A.]

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

[PHP-DEV] [PATCH] ereg to pcre conversion

[Ilia A.]

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

[PHP-DEV] safe_mode_include_dir option

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: run-tests.php & errors/warnings

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] I hope this is the last email about this :)

[Ilia A.]

+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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php

[Ilia A.]

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  and  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;
> > }
> > }
> >+   }
> >+

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php

[Ilia A.]

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
>  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 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Regex Libraries

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] parse_url still broken!

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [4.3] Current critical bugs

[Ilia A.]

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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

[Ilia A.]

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 "
> 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  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,
> ";?> 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 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

[Ilia A.]

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  > 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 "" works always and authors of portable
> scripts should use it. If there are new processing tags,
> echo "" 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 http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php