Re: [PHP-DEV] Is this a bug?

2003-03-25 Thread Chris Shiflett
--- Tony Bibbs [EMAIL PROTECTED] wrote:
 Are there instances you all can think of where doing a header('location: 
 $url'); causes a loss of all session data?

This is most likely not a bug. You can (hopefully) find more people to help
with this type of question on [EMAIL PROTECTED]

Good luck.

Chris

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



Re: [PHP-DEV] Proposed fix for bug #21149

2002-12-23 Thread Melvyn Sopacua
On Mon, 23 Dec 2002, Ilia A. wrote:

IA The current implementation of php_register_variable_ex() improperly handles 
IA situations when the name of the variable passed via GET/POST/COOKIES contains 
IA a '[' or it's urlencoded equivalent. The result is a small memory leak 
IA (number of chars between '[' and '=' +1) and invalid data inside the 
IA GET/POST/COOKIES array.
IA The proposed patch makes php_register_variable_ex aware that [ may not be 
IA terminated and adds handling for such conditions. The end result is that the 
IA code no longer leaks memory  can support variable passed via 
IA GET/POST/COOKIES with '[' in their names.
IA 

[02:21] ilia melvyn: +1 it :)
[02:23] melvyn ilia: not sure that's gonna help with my karma factor :)
[02:23] ilia melvyn: doesn't matter :)

so -ehm +1?
-- 
With kind regards,

Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?


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




Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Marcus Börger
I am not sure if va_start can be called twice in a row (rekursive).
Manual does not say anything about that.

How about:

cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
+++ zend_hash.c 8 Nov 2002 09:32:48 -
 -722,9 +722,13 

HASH_PROTECT_RECURSION(ht);

-   va_start(args, num_args);
p = ht-pListHead;
+   if (p == NULL) {
+   va_start(args, num_args);
+   va_end(args);
+   }
while (p != NULL) {
+   va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
 -733,8 +737,8 
} else {
p = p-pListNext;
}
+   va_end(args);
}
-   va_end(args);

HASH_UNPROTECT_RECURSION(ht);
 }


marcus

At 09:52 08.11.2002, Moriyoshi Koizumi wrote:

Hi,

The attached patch is a probable fix for bug #19566. I guess the bug
is that va_list is not properly initialized before each callback function
call. I've tested it in PPC linux, and it works fine.

Regards,
Moriyoshi


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



Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Moriyoshi Koizumi
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.

And I don't think va_start() always has to be invoked.

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

 I am not sure if va_start can be called twice in a row (rekursive).
 Manual does not say anything about that.
 
 How about:
 
 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 09:32:48 -
 @@ -722,9 +722,13 @@
 
  HASH_PROTECT_RECURSION(ht);
 
 -   va_start(args, num_args);
  p = ht-pListHead;
 +   if (p == NULL) {
 +   va_start(args, num_args);
 +   va_end(args);
 +   }
  while (p != NULL) {
 +   va_start(args, num_args);
  hash_key.arKey = p-arKey;
  hash_key.nKeyLength = p-nKeyLength;
  hash_key.h = p-h;
 @@ -733,8 +737,8 @@
  } else {
  p = p-pListNext;
  }
 +   va_end(args);
  }
 -   va_end(args);
 
  HASH_UNPROTECT_RECURSION(ht);
   }
 
 
 marcus
 
 At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
 Hi,
 
 The attached patch is a probable fix for bug #19566. I guess the bug
 is that va_list is not properly initialized before each callback function
 call. I've tested it in PPC linux, and it works fine.
 
 Regards,
 Moriyoshi
 
 
 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Marcus Börger
Some comments on ISO9899 standard
7.15.1.3-2 Read between the lines: without va_end the behaviour is undefined.
 What ever that means i guess you have to call va_end and that requires 
va_start.

7.15.1.4-3 Says do not call va_start twice without va_end.

marcus


ISO/IEC 9899:1999 (E) ©ISO/IEC

7.15.1.3 The va_end macro
Synopsis
1 #include stdarg.h
void va_end(va_list ap);
Description
2 The va_end macro facilitates a normal return from the function whose variable
argument list was referred to by the expansion of va_start, or the function 
containing
the expansion of va_copy, that initialized the va_list ap. The va_end macro may
modify ap so that it is no longer usable (without an intervening invocation 
of va_start
or va_copy). If there is no corresponding invocation of the va_start or va_copy
macro, or if the va_end macro is not invoked before the return, the behavior is
undefined.
Returns
3 The va_end macro returns no value.

7.15.1.4 The va_start macro
Synopsis
1 #include stdarg.h
void va_start(va_list ap, parmN);
Description
2 The va_start macro shall be invoked before any access to the unnamed 
arguments.
3 The va_start macro initializes ap for subsequent use by va_arg and va_end.
va_start (or va_copy) shall not be invoked again for the same ap without an
intervening invocation of va_end for the same ap.
(...)


At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.

And I don't think va_start() always has to be invoked.

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

 I am not sure if va_start can be called twice in a row (rekursive).
 Manual does not say anything about that.

 How about:

 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 09:32:48 -
 @@ -722,9 +722,13 @@

  HASH_PROTECT_RECURSION(ht);

 -   va_start(args, num_args);
  p = ht-pListHead;
 +   if (p == NULL) {
 +   va_start(args, num_args);
 +   va_end(args);
 +   }
  while (p != NULL) {
 +   va_start(args, num_args);
  hash_key.arKey = p-arKey;
  hash_key.nKeyLength = p-nKeyLength;
  hash_key.h = p-h;
 @@ -733,8 +737,8 @@
  } else {
  p = p-pListNext;
  }
 +   va_end(args);
  }
 -   va_end(args);

  HASH_UNPROTECT_RECURSION(ht);
   }


 marcus

 At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
 Hi,
 
 The attached patch is a probable fix for bug #19566. I guess the bug
 is that va_list is not properly initialized before each callback function
 call. I've tested it in PPC linux, and it works fine.
 
 Regards,
 Moriyoshi
 
 
 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Moriyoshi Koizumi
Yep, the spec goes right. a corresponding va_end() dtor should be applied 
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't 
matter if ap is used between va_start() and va_end().

BTW, could anyone commit this patch if there seems no problem?

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

 Some comments on ISO9899 standard
 7.15.1.3-2 Read between the lines: without va_end the behaviour is undefined.
   What ever that means i guess you have to call va_end and that requires 
 va_start.
 
 7.15.1.4-3 Says do not call va_start twice without va_end.
 
 marcus
 
 
 ISO/IEC 9899:1999 (E) ©ISO/IEC
 
 7.15.1.3 The va_end macro
 Synopsis
 1 #include stdarg.h
 void va_end(va_list ap);
 Description
 2 The va_end macro facilitates a normal return from the function whose variable
 argument list was referred to by the expansion of va_start, or the function 
 containing
 the expansion of va_copy, that initialized the va_list ap. The va_end macro may
 modify ap so that it is no longer usable (without an intervening invocation 
 of va_start
 or va_copy). If there is no corresponding invocation of the va_start or va_copy
 macro, or if the va_end macro is not invoked before the return, the behavior is
 undefined.
 Returns
 3 The va_end macro returns no value.
 
 7.15.1.4 The va_start macro
 Synopsis
 1 #include stdarg.h
 void va_start(va_list ap, parmN);
 Description
 2 The va_start macro shall be invoked before any access to the unnamed 
 arguments.
 3 The va_start macro initializes ap for subsequent use by va_arg and va_end.
 va_start (or va_copy) shall not be invoked again for the same ap without an
 intervening invocation of va_end for the same ap.
 (...)
 
 
 At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
 See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
 This appears to imply that va_start() can be used more than twice.
 
 And I don't think va_start() always has to be invoked.
 
 Moriyoshi
 
 [EMAIL PROTECTED] (Marcus Börger) wrote:
 
   I am not sure if va_start can be called twice in a row (rekursive).
   Manual does not say anything about that.
  
   How about:
  
   cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
   Index: zend_hash.c
   ===
   RCS file: /repository/ZendEngine2/zend_hash.c,v
   retrieving revision 1.93
   diff -u -r1.93 zend_hash.c
   --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
   +++ zend_hash.c 8 Nov 2002 09:32:48 -
   @@ -722,9 +722,13 @@
  
HASH_PROTECT_RECURSION(ht);
  
   -   va_start(args, num_args);
p = ht-pListHead;
   +   if (p == NULL) {
   +   va_start(args, num_args);
   +   va_end(args);
   +   }
while (p != NULL) {
   +   va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
   @@ -733,8 +737,8 @@
} else {
p = p-pListNext;
}
   +   va_end(args);
}
   -   va_end(args);
  
HASH_UNPROTECT_RECURSION(ht);
 }
  
  
   marcus
  
   At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
   Hi,
   
   The attached patch is a probable fix for bug #19566. I guess the bug
   is that va_list is not properly initialized before each callback function
   call. I've tested it in PPC linux, and it works fine.
   
   Regards,
   Moriyoshi
   
   
   --
   PHP Development Mailing List http://www.php.net/
   To unsubscribe, visit: http://www.php.net/unsub.php


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




Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Marcus Börger
Moriyoshi  could you make a *.phpt file from the bug?

Attached is a new diff tested already. It also fixes a compiler warning.
Since i do not have Zend karma someone with karma should commit it
or give me karma.

marcus

cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
===
RCS file: /repository/ZendEngine2/zend_hash.c,v
retrieving revision 1.93
diff -u -r1.93 zend_hash.c
--- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
+++ zend_hash.c 8 Nov 2002 17:25:59 -
@@ -722,9 +722,9 @@

HASH_PROTECT_RECURSION(ht);

-   va_start(args, num_args);
p = ht-pListHead;
while (p != NULL) {
+   va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
@@ -733,8 +733,8 @@
} else {
p = p-pListNext;
}
+   va_end(args);
}
-   va_end(args);

HASH_UNPROTECT_RECURSION(ht);
 }
@@ -1163,7 +1163,7 @@

 ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2, 
compare_func_t compar, zend_bool ordered TSRMLS_DC)
 {
-   Bucket *p1, *p2;
+   Bucket *p1, *p2 = NULL /* fixes warning */;
int result;
void *pData2;



At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
Yep, the spec goes right. a corresponding va_end() dtor should be applied
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't
matter if ap is used between va_start() and va_end().

BTW, could anyone commit this patch if there seems no problem?

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

 Some comments on ISO9899 standard
 7.15.1.3-2 Read between the lines: without va_end the behaviour is 
undefined.
   What ever that means i guess you have to call va_end and that requires
 va_start.

 7.15.1.4-3 Says do not call va_start twice without va_end.

 marcus


 ISO/IEC 9899:1999 (E) ©ISO/IEC

 7.15.1.3 The va_end macro
 Synopsis
 1 #include stdarg.h
 void va_end(va_list ap);
 Description
 2 The va_end macro facilitates a normal return from the function whose 
variable
 argument list was referred to by the expansion of va_start, or the 
function
 containing
 the expansion of va_copy, that initialized the va_list ap. The va_end 
macro may
 modify ap so that it is no longer usable (without an intervening 
invocation
 of va_start
 or va_copy). If there is no corresponding invocation of the va_start or 
va_copy
 macro, or if the va_end macro is not invoked before the return, the 
behavior is
 undefined.
 Returns
 3 The va_end macro returns no value.

 7.15.1.4 The va_start macro
 Synopsis
 1 #include stdarg.h
 void va_start(va_list ap, parmN);
 Description
 2 The va_start macro shall be invoked before any access to the unnamed
 arguments.
 3 The va_start macro initializes ap for subsequent use by va_arg and 
va_end.
 va_start (or va_copy) shall not be invoked again for the same ap without an
 intervening invocation of va_end for the same ap.
 (...)


 At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
 See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
 This appears to imply that va_start() can be used more than twice.
 
 And I don't think va_start() always has to be invoked.
 
 Moriyoshi
 
 [EMAIL PROTECTED] (Marcus Börger) wrote:
 
   I am not sure if va_start can be called twice in a row (rekursive).
   Manual does not say anything about that.
  
   How about:
  
   cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
   Index: zend_hash.c
   ===
   RCS file: /repository/ZendEngine2/zend_hash.c,v
   retrieving revision 1.93
   diff -u -r1.93 zend_hash.c
   --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
   +++ zend_hash.c 8 Nov 2002 09:32:48 -
   @@ -722,9 +722,13 @@
  
HASH_PROTECT_RECURSION(ht);
  
   -   va_start(args, num_args);
p = ht-pListHead;
   +   if (p == NULL) {
   +   va_start(args, num_args);
   +   va_end(args);
   +   }
while (p != NULL) {
   +   va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
   @@ -733,8 +737,8 @@
} else {
p = p-pListNext;
}
   +   va_end(args);
}
   -   va_end(args);
  
HASH_UNPROTECT_RECURSION(ht);
 }
  
  
   marcus
  
   At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
   Hi,
   
   The attached patch is a probable fix for bug #19566. I guess the bug
   is that va_list is not properly initialized before each callback 
function
   call. I've tested it in PPC linux, and it works fine.
   
   Regards,
   Moriyoshi
   
   
   --

Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Moriyoshi Koizumi
done.

Moriyoshi

[EMAIL PROTECTED] (Marcus Börger) wrote:

 Moriyoshi  could you make a *.phpt file from the bug?
 
 Attached is a new diff tested already. It also fixes a compiler warning.
 Since i do not have Zend karma someone with karma should commit it
 or give me karma.
 
 marcus
 
 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 17:25:59 -
 @@ -722,9 +722,9 @@
 
  HASH_PROTECT_RECURSION(ht);
 
 -   va_start(args, num_args);
  p = ht-pListHead;
  while (p != NULL) {
 +   va_start(args, num_args);
  hash_key.arKey = p-arKey;
  hash_key.nKeyLength = p-nKeyLength;
  hash_key.h = p-h;
 @@ -733,8 +733,8 @@
  } else {
  p = p-pListNext;
  }
 +   va_end(args);
  }
 -   va_end(args);
 
  HASH_UNPROTECT_RECURSION(ht);
   }
 @@ -1163,7 +1163,7 @@
 
   ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2, 
 compare_func_t compar, zend_bool ordered TSRMLS_DC)
   {
 -   Bucket *p1, *p2;
 +   Bucket *p1, *p2 = NULL /* fixes warning */;
  int result;
  void *pData2;
 
 
 
 At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
 Yep, the spec goes right. a corresponding va_end() dtor should be applied
 to ap once ap has been initialized by a va_start().
 IMO no va_end() is needed without a preceding va_start(), and it doesn't
 matter if ap is used between va_start() and va_end().
 
 BTW, could anyone commit this patch if there seems no problem?
 
 Moriyoshi
 
 [EMAIL PROTECTED] (Marcus Börger) wrote:
 
   Some comments on ISO9899 standard
   7.15.1.3-2 Read between the lines: without va_end the behaviour is 
  undefined.
 What ever that means i guess you have to call va_end and that requires
   va_start.
  
   7.15.1.4-3 Says do not call va_start twice without va_end.
  
   marcus
  
  
   ISO/IEC 9899:1999 (E) ©ISO/IEC
  
   7.15.1.3 The va_end macro
   Synopsis
   1 #include stdarg.h
   void va_end(va_list ap);
   Description
   2 The va_end macro facilitates a normal return from the function whose 
  variable
   argument list was referred to by the expansion of va_start, or the 
  function
   containing
   the expansion of va_copy, that initialized the va_list ap. The va_end 
  macro may
   modify ap so that it is no longer usable (without an intervening 
  invocation
   of va_start
   or va_copy). If there is no corresponding invocation of the va_start or 
  va_copy
   macro, or if the va_end macro is not invoked before the return, the 
  behavior is
   undefined.
   Returns
   3 The va_end macro returns no value.
  
   7.15.1.4 The va_start macro
   Synopsis
   1 #include stdarg.h
   void va_start(va_list ap, parmN);
   Description
   2 The va_start macro shall be invoked before any access to the unnamed
   arguments.
   3 The va_start macro initializes ap for subsequent use by va_arg and 
  va_end.
   va_start (or va_copy) shall not be invoked again for the same ap without an
   intervening invocation of va_end for the same ap.
   (...)
  
  
   At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
   See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
   This appears to imply that va_start() can be used more than twice.
   
   And I don't think va_start() always has to be invoked.
   
   Moriyoshi
   
   [EMAIL PROTECTED] (Marcus Börger) wrote:
   
 I am not sure if va_start can be called twice in a row (rekursive).
 Manual does not say anything about that.

 How about:

 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 09:32:48 -
 @@ -722,9 +722,13 @@

  HASH_PROTECT_RECURSION(ht);

 -   va_start(args, num_args);
  p = ht-pListHead;
 +   if (p == NULL) {
 +   va_start(args, num_args);
 +   va_end(args);
 +   }
  while (p != NULL) {
 +   va_start(args, num_args);
  hash_key.arKey = p-arKey;
  hash_key.nKeyLength = p-nKeyLength;
  hash_key.h = p-h;
 @@ -733,8 +737,8 @@
  } else {
  p = p-pListNext;
  }
 +   va_end(args);
  }
 -   va_end(args);

  HASH_UNPROTECT_RECURSION(ht);
 

Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Derick Rethans
On Fri, 8 Nov 2002, Marcus Börger wrote:

 Moriyoshi  could you make a *.phpt file from the bug?
 
 Attached is a new diff tested already. It also fixes a compiler warning.
 Since i do not have Zend karma someone with karma should commit it
 or give me karma.

I can commit this, after you fix the whitespace :)

Derick

 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 17:25:59 -
 @@ -722,9 +722,9 @@
 
  HASH_PROTECT_RECURSION(ht);
 
 -   va_start(args, num_args);
  p = ht-pListHead;
  while (p != NULL) {
 +   va_start(args, num_args);
  hash_key.arKey = p-arKey;
  hash_key.nKeyLength = p-nKeyLength;
  hash_key.h = p-h;
 @@ -733,8 +733,8 @@
  } else {
  p = p-pListNext;
  }
 +   va_end(args);
  }
 -   va_end(args);
 
  HASH_UNPROTECT_RECURSION(ht);
   }
 @@ -1163,7 +1163,7 @@
 
   ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2, 
 compare_func_t compar, zend_bool ordered TSRMLS_DC)
   {
 -   Bucket *p1, *p2;
 +   Bucket *p1, *p2 = NULL /* fixes warning */;
  int result;
  void *pData2;
 
 
 
 At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
 Yep, the spec goes right. a corresponding va_end() dtor should be applied
 to ap once ap has been initialized by a va_start().
 IMO no va_end() is needed without a preceding va_start(), and it doesn't
 matter if ap is used between va_start() and va_end().
 
 BTW, could anyone commit this patch if there seems no problem?
 
 Moriyoshi
 
 [EMAIL PROTECTED] (Marcus Börger) wrote:
 
   Some comments on ISO9899 standard
   7.15.1.3-2 Read between the lines: without va_end the behaviour is 
  undefined.
 What ever that means i guess you have to call va_end and that requires
   va_start.
  
   7.15.1.4-3 Says do not call va_start twice without va_end.
  
   marcus
  
  
   ISO/IEC 9899:1999 (E) ©ISO/IEC
  
   7.15.1.3 The va_end macro
   Synopsis
   1 #include stdarg.h
   void va_end(va_list ap);
   Description
   2 The va_end macro facilitates a normal return from the function whose 
  variable
   argument list was referred to by the expansion of va_start, or the 
  function
   containing
   the expansion of va_copy, that initialized the va_list ap. The va_end 
  macro may
   modify ap so that it is no longer usable (without an intervening 
  invocation
   of va_start
   or va_copy). If there is no corresponding invocation of the va_start or 
  va_copy
   macro, or if the va_end macro is not invoked before the return, the 
  behavior is
   undefined.
   Returns
   3 The va_end macro returns no value.
  
   7.15.1.4 The va_start macro
   Synopsis
   1 #include stdarg.h
   void va_start(va_list ap, parmN);
   Description
   2 The va_start macro shall be invoked before any access to the unnamed
   arguments.
   3 The va_start macro initializes ap for subsequent use by va_arg and 
  va_end.
   va_start (or va_copy) shall not be invoked again for the same ap without an
   intervening invocation of va_end for the same ap.
   (...)
  
  
   At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
   See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
   This appears to imply that va_start() can be used more than twice.
   
   And I don't think va_start() always has to be invoked.
   
   Moriyoshi
   
   [EMAIL PROTECTED] (Marcus Börger) wrote:
   
 I am not sure if va_start can be called twice in a row (rekursive).
 Manual does not say anything about that.

 How about:

 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 09:32:48 -
 @@ -722,9 +722,13 @@

  HASH_PROTECT_RECURSION(ht);

 -   va_start(args, num_args);
  p = ht-pListHead;
 +   if (p == NULL) {
 +   va_start(args, num_args);
 +   va_end(args);
 +   }
  while (p != NULL) {
 +   va_start(args, num_args);
  hash_key.arKey = p-arKey;
  hash_key.nKeyLength = p-nKeyLength;
  hash_key.h = p-h;
 @@ -733,8 +737,8 @@
  } else {
  p = p-pListNext;
  }
 +   va_end(args);
  }
 -   va_end(args);

  

Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Andi Gutmans
I haven't followed the thread. What is the problem with the var_args()?
Also, please don't commit the second part of the patch. The warning is due 
to the compiler not understanding the code well enough. Functionality wise 
there's no reason to NULL that variable. Live with the warning or upgrade 
to a better compiler.

Andi

At 07:25 PM 11/8/2002 +0100, Derick Rethans wrote:
On Fri, 8 Nov 2002, Marcus Börger wrote:

 Moriyoshi  could you make a *.phpt file from the bug?

 Attached is a new diff tested already. It also fixes a compiler warning.
 Since i do not have Zend karma someone with karma should commit it
 or give me karma.

I can commit this, after you fix the whitespace :)

Derick

 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 17:25:59 -
 @@ -722,9 +722,9 @@

  HASH_PROTECT_RECURSION(ht);

 -   va_start(args, num_args);
  p = ht-pListHead;
  while (p != NULL) {
 +   va_start(args, num_args);
  hash_key.arKey = p-arKey;
  hash_key.nKeyLength = p-nKeyLength;
  hash_key.h = p-h;
 @@ -733,8 +733,8 @@
  } else {
  p = p-pListNext;
  }
 +   va_end(args);
  }
 -   va_end(args);

  HASH_UNPROTECT_RECURSION(ht);
   }
 @@ -1163,7 +1163,7 @@

   ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2,
 compare_func_t compar, zend_bool ordered TSRMLS_DC)
   {
 -   Bucket *p1, *p2;
 +   Bucket *p1, *p2 = NULL /* fixes warning */;
  int result;
  void *pData2;



 At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
 Yep, the spec goes right. a corresponding va_end() dtor should be applied
 to ap once ap has been initialized by a va_start().
 IMO no va_end() is needed without a preceding va_start(), and it doesn't
 matter if ap is used between va_start() and va_end().
 
 BTW, could anyone commit this patch if there seems no problem?
 
 Moriyoshi
 
 [EMAIL PROTECTED] (Marcus Börger) wrote:
 
   Some comments on ISO9899 standard
   7.15.1.3-2 Read between the lines: without va_end the behaviour is
  undefined.
 What ever that means i guess you have to call va_end and that 
requires
   va_start.
  
   7.15.1.4-3 Says do not call va_start twice without va_end.
  
   marcus
  
  
   ISO/IEC 9899:1999 (E) ©ISO/IEC
  
   7.15.1.3 The va_end macro
   Synopsis
   1 #include stdarg.h
   void va_end(va_list ap);
   Description
   2 The va_end macro facilitates a normal return from the function whose
  variable
   argument list was referred to by the expansion of va_start, or the
  function
   containing
   the expansion of va_copy, that initialized the va_list ap. The va_end
  macro may
   modify ap so that it is no longer usable (without an intervening
  invocation
   of va_start
   or va_copy). If there is no corresponding invocation of the 
va_start or
  va_copy
   macro, or if the va_end macro is not invoked before the return, the
  behavior is
   undefined.
   Returns
   3 The va_end macro returns no value.
  
   7.15.1.4 The va_start macro
   Synopsis
   1 #include stdarg.h
   void va_start(va_list ap, parmN);
   Description
   2 The va_start macro shall be invoked before any access to the unnamed
   arguments.
   3 The va_start macro initializes ap for subsequent use by va_arg and
  va_end.
   va_start (or va_copy) shall not be invoked again for the same ap 
without an
   intervening invocation of va_end for the same ap.
   (...)
  
  
   At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
   See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
   This appears to imply that va_start() can be used more than twice.
   
   And I don't think va_start() always has to be invoked.
   
   Moriyoshi
   
   [EMAIL PROTECTED] (Marcus Börger) wrote:
   
 I am not sure if va_start can be called twice in a row (rekursive).
 Manual does not say anything about that.

 How about:

 cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
 Index: zend_hash.c
 ===
 RCS file: /repository/ZendEngine2/zend_hash.c,v
 retrieving revision 1.93
 diff -u -r1.93 zend_hash.c
 --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
 +++ zend_hash.c 8 Nov 2002 09:32:48 -
 @@ -722,9 +722,13 @@

  HASH_PROTECT_RECURSION(ht);

 -   va_start(args, num_args);
  p = ht-pListHead;
 +   if (p == NULL) {
 +   va_start(args, num_args);
 +   va_end(args);
 +   }
  while (p != NULL) {
 +   va_start(args, num_args);
 

Re: [PHP-DEV] [PATCH] Fix for bug #19566

2002-11-08 Thread Moriyoshi Koizumi
var_args issue doesn't have much to do with the purpose of the patch. We 
were perhaps just curious about the usage of va_start() and va_end().
And that warning reducer was later added by Marcus, so the first version 
should look nice. What about it?

Moriyoshi

Andi Gutmans [EMAIL PROTECTED] wrote:

 I haven't followed the thread. What is the problem with the var_args()?
 Also, please don't commit the second part of the patch. The warning is due 
 to the compiler not understanding the code well enough. Functionality wise 
 there's no reason to NULL that variable. Live with the warning or upgrade 
 to a better compiler.
 
 Andi
 
 At 07:25 PM 11/8/2002 +0100, Derick Rethans wrote:
 On Fri, 8 Nov 2002, Marcus Börger wrote:
 
   Moriyoshi  could you make a *.phpt file from the bug?
  
   Attached is a new diff tested already. It also fixes a compiler warning.
   Since i do not have Zend karma someone with karma should commit it
   or give me karma.
 
 I can commit this, after you fix the whitespace :)
 
 Derick
 
   cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
   Index: zend_hash.c
   ===
   RCS file: /repository/ZendEngine2/zend_hash.c,v
   retrieving revision 1.93
   diff -u -r1.93 zend_hash.c
   --- zend_hash.c 5 Nov 2002 18:22:02 -   1.93
   +++ zend_hash.c 8 Nov 2002 17:25:59 -
   @@ -722,9 +722,9 @@
  
HASH_PROTECT_RECURSION(ht);
  
   -   va_start(args, num_args);
p = ht-pListHead;
while (p != NULL) {
   +   va_start(args, num_args);
hash_key.arKey = p-arKey;
hash_key.nKeyLength = p-nKeyLength;
hash_key.h = p-h;
   @@ -733,8 +733,8 @@
} else {
p = p-pListNext;
}
   +   va_end(args);
}
   -   va_end(args);
  
HASH_UNPROTECT_RECURSION(ht);
 }
   @@ -1163,7 +1163,7 @@
  
 ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2,
   compare_func_t compar, zend_bool ordered TSRMLS_DC)
 {
   -   Bucket *p1, *p2;
   +   Bucket *p1, *p2 = NULL /* fixes warning */;
int result;
void *pData2;
  
  
  
   At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
   Yep, the spec goes right. a corresponding va_end() dtor should be applied
   to ap once ap has been initialized by a va_start().
   IMO no va_end() is needed without a preceding va_start(), and it doesn't
   matter if ap is used between va_start() and va_end().
   
   BTW, could anyone commit this patch if there seems no problem?
   
   Moriyoshi
   
   [EMAIL PROTECTED] (Marcus Börger) wrote:
   
 Some comments on ISO9899 standard
 7.15.1.3-2 Read between the lines: without va_end the behaviour is
undefined.
   What ever that means i guess you have to call va_end and that 
  requires
 va_start.

 7.15.1.4-3 Says do not call va_start twice without va_end.

 marcus


 ISO/IEC 9899:1999 (E) ©ISO/IEC

 7.15.1.3 The va_end macro
 Synopsis
 1 #include stdarg.h
 void va_end(va_list ap);
 Description
 2 The va_end macro facilitates a normal return from the function whose
variable
 argument list was referred to by the expansion of va_start, or the
function
 containing
 the expansion of va_copy, that initialized the va_list ap. The va_end
macro may
 modify ap so that it is no longer usable (without an intervening
invocation
 of va_start
 or va_copy). If there is no corresponding invocation of the 
  va_start or
va_copy
 macro, or if the va_end macro is not invoked before the return, the
behavior is
 undefined.
 Returns
 3 The va_end macro returns no value.

 7.15.1.4 The va_start macro
 Synopsis
 1 #include stdarg.h
 void va_start(va_list ap, parmN);
 Description
 2 The va_start macro shall be invoked before any access to the unnamed
 arguments.
 3 The va_start macro initializes ap for subsequent use by va_arg and
va_end.
 va_start (or va_copy) shall not be invoked again for the same ap 
  without an
 intervening invocation of va_end for the same ap.
 (...)


 At 10:47 08.11.2002, Moriyoshi Koizumi wrote:
 See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
 This appears to imply that va_start() can be used more than twice.
 
 And I don't think va_start() always has to be invoked.
 
 Moriyoshi
 
 [EMAIL PROTECTED] (Marcus Börger) wrote:
 
   I am not sure if va_start can be called twice in a row (rekursive).
   Manual does not say anything about that.
  
   How about:
  
   cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend)
   Index: zend_hash.c
   ===
   

Re: [PHP-DEV] Re: Ming streams bug

2002-10-15 Thread Rasmus Lerdorf

It's just a spinning logo flash movie.  I have attached the script and the
little logo image it spins.

And no, I didn't try the two separately yet.

-Rasmus

On Wed, 16 Oct 2002, Wez Furlong wrote:

 have you got a script I can try out?

 Did you try A and B separately?

 I might not be able to reproduce this, because my glibc is the older
 flavour :-/
 I'll give it a go though!

 --Wez.

 On 16/10/02, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
   A. toggle the configure detected value for COOKIE_SEEKER_USES_FPOS_T
   then recompile.
 
  It was undefined.  I defined it.
 
   B. #undef HAVE_FOPENCOOKIE then recompile.
 
  It was defined, I undefined it.
 
  Make clean, recompile and try again.  Exactly the same segfault.
 
  -Rasmus




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



?
$s = new SWFShape();
$fp = fopen('php-big.jpg','r');
$jpg = new SWFBitmap($fp);
fclose($fp);
$w = $jpg-getWidth(); $h = $jpg-getHeight();

$f = $s-addFill($jpg);
$f-moveTo(-$w/2, -$h/2);
$s-setRightFill($f);

$s-movePenTo(-$w/2, -$h/2);
$s-drawLine($w, 0);
$s-drawLine(0, $h);
$s-drawLine(-$w, 0);
$s-drawLine(0, -$h);

$p = new SWFSprite();
$i = $p-add($s);

for($step=0; $step360; $step+=2) {
$p-nextFrame();
$i-rotate(-2);
}

$m = new SWFMovie();
$i = $m-add($p);
$i-moveTo(230,120);
$m-setRate(100);
$m-setDimension($w*1.8, $h*1.8);

header('Content-type: application/x-shockwave-flash');
$m-output();
?


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


Re: [PHP-DEV] Re: Ming streams bug

2002-10-15 Thread Wez Furlong

Try taking out the fclose($fp) line :-)

fclose nukes the stream (just like all the other resource freeing functions)
so it's not valid by the time that ming goes to use it = crash.

Replacing fclose($fp) with $fp = null; is probably the correct thing to
do in the script; there is not much that can be done to prevent the crash
from happening :-/

--Wez.

On 16/10/02, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
 It's just a spinning logo flash movie.  I have attached the script and the
 little logo image it spins.
 
 And no, I didn't try the two separately yet.
 
 -Rasmus
 
 On Wed, 16 Oct 2002, Wez Furlong wrote:
 
  have you got a script I can try out?
 
  Did you try A and B separately?
 
  I might not be able to reproduce this, because my glibc is the older
  flavour :-/
  I'll give it a go though!
 
  --Wez.
 
  On 16/10/02, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
A. toggle the configure detected value for COOKIE_SEEKER_USES_FPOS_T
then recompile.
  
   It was undefined.  I defined it.
  
B. #undef HAVE_FOPENCOOKIE then recompile.
  
   It was defined, I undefined it.
  
   Make clean, recompile and try again.  Exactly the same segfault.
  
   -Rasmus
 
 
 
 
  --
  PHP Development Mailing List http://www.php.net/
  To unsubscribe, visit: http://www.php.net/unsub.php
 




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




Re: [PHP-DEV] Re: Ming streams bug

2002-10-15 Thread Rasmus Lerdorf

Hrm..  That does fix it.  This has worked for ages with the fclose though.
A bunch of leaks though:

/home/rasmus/php4/Zend/zend_hash.c(178) :  Freeing 0x08325DCC (32 bytes), 
script=ming.php
Last leak repeated 3 times
/home/rasmus/php4/Zend/zend_API.c(597) :  Freeing 0x08325D6C (44 bytes), 
script=ming.php
/home/rasmus/php4/Zend/zend_API.c(585) : Actual location (location was relayed)
Last leak repeated 3 times

I'll have a look at those.

-Rasmus

On Wed, 16 Oct 2002, Wez Furlong wrote:

 Try taking out the fclose($fp) line :-)

 fclose nukes the stream (just like all the other resource freeing functions)
 so it's not valid by the time that ming goes to use it = crash.

 Replacing fclose($fp) with $fp = null; is probably the correct thing to
 do in the script; there is not much that can be done to prevent the crash
 from happening :-/

 --Wez.

 On 16/10/02, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
  It's just a spinning logo flash movie.  I have attached the script and the
  little logo image it spins.
 
  And no, I didn't try the two separately yet.
 
  -Rasmus
 
  On Wed, 16 Oct 2002, Wez Furlong wrote:
 
   have you got a script I can try out?
  
   Did you try A and B separately?
  
   I might not be able to reproduce this, because my glibc is the older
   flavour :-/
   I'll give it a go though!
  
   --Wez.
  
   On 16/10/02, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
 A. toggle the configure detected value for COOKIE_SEEKER_USES_FPOS_T
 then recompile.
   
It was undefined.  I defined it.
   
 B. #undef HAVE_FOPENCOOKIE then recompile.
   
It was defined, I undefined it.
   
Make clean, recompile and try again.  Exactly the same segfault.
   
-Rasmus
  
  
  
  
   --
   PHP Development Mailing List http://www.php.net/
   To unsubscribe, visit: http://www.php.net/unsub.php
  





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




Re: [PHP-DEV] [PATCH] fix for bug #18654

2002-08-20 Thread Sander Roobol

Thanks, I've committed the patch to CVS.

Sander

On Mon, Aug 19, 2002 at 03:42:12PM +0200, Christophe Sollet wrote:
 hi,
this patch fix bug #18654 by extending the nvexp definition.
The diff contains the resulting re2c var_unserializer.c.
 
 [snip]
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 

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




Re: [PHP-DEV] [PATCH] fix for bug #18654

2002-08-20 Thread Christophe Sollet

Sander Roobol wrote:

Can it be merged in the 4.2 branch too ?
It would be great to have 4.2.3 without this bug.

Christophe


Thanks, I've committed the patch to CVS.

Sander

On Mon, Aug 19, 2002 at 03:42:12PM +0200, Christophe Sollet wrote:
  

hi,
   this patch fix bug #18654 by extending the nvexp definition.
   The diff contains the resulting re2c var_unserializer.c.

[snip]

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





  





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




Re: [PHP-DEV] [PATCH] fix for bug #18654

2002-08-20 Thread Sander Roobol

Yeah, should have done that immediately. Committed.

On Tue, Aug 20, 2002 at 09:41:54PM +0200, Christophe Sollet wrote:
 Sander Roobol wrote:
 
 Can it be merged in the 4.2 branch too ?
 It would be great to have 4.2.3 without this bug.
 
 Christophe
 
 
 Thanks, I've committed the patch to CVS.
 
 Sander
 
 On Mon, Aug 19, 2002 at 03:42:12PM +0200, Christophe Sollet wrote:
  
 
 hi,
   this patch fix bug #18654 by extending the nvexp definition.
   The diff contains the resulting re2c var_unserializer.c.
 
 [snip]
 
 -- 
 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] Tru64, snprintf and bug #1298

2002-08-17 Thread Sebastian Nohn

Maybe U should say that I use gcc (2.9) under Tru64, the other thing is that
I've experienced most bugs also under Linux/Alpha and FreeBSD/Alpha, so I
think it's 64-bit in most cases.

 -Original Message-
 From: Dan Kalowsky [mailto:[EMAIL PROTECTED]]
 Sent: Saturday, August 17, 2002 5:44 AM
 To: [EMAIL PROTECTED]
 Cc: PHP Development Mailing list
 Subject: Re: [PHP-DEV] Tru64, snprintf and bug #1298


 Well it's starting to sound like it might be necessary to do this.  While
 nohn's compiler is working, it seems that at least one other Tru64 person
 is having difficulty.

 Looking at the influx of bugs as well, I'm wondering if Tru64 is going to
 be more of a problem for the project as whole... or if it's just 64-bit
 arch's in the end.

 On Sat, 17 Aug 2002, Marcus [iso-8859-1] Börger wrote:

  First of all the internal replacement of snprintf fails if size
 is 1 or 0.
  Second it is not C99 complient and third we do not include it the
  right way. We would need to check if snprintf is available and if it is
  C99 complient and if not use the replacement.
 
  I had a lengthy discussion with the php group on that but i did
  not get any answer at last. This might be the case because my
  first worst assumptions were wrong for most systems.
 
  In fact i could commit detection code and corect replacement code
  but will do only when receiving a go from the group.
 
  regards
  marcus
 
  At 23:31 16.08.2002, Dan Kalowsky wrote:
  Yes, that is correct, bug #1298 (it's existed for a LONG time).
  
  The user is having some difficulty compiling the Zend
 libraries for 4.2.2.
  Mainly it seems that snprintf is turning up as an unresolved symbol.
  I asked him to grep through the /usr/include looking for it, and the
  result was nothing.
  
  Looking through the code I see PHP has it's own snprintf
 implementation,
  and that should suffice.  Apparently zend_API.c though doesn't
 notice it.
  His fix was to place #include php.h inside the file, and everything
  worked fine.
  
  Does anyone have any more insight into this that they might be able to
  share?
  


Regards,
   Sebastian Nohn
--
+49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/
PGP Key Available - Did I help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/


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




Re: [PHP-DEV] Tru64, snprintf and bug #1298

2002-08-16 Thread Marcus Börger

First of all the internal replacement of snprintf fails if size is 1 or 0.
Second it is not C99 complient and third we do not include it the
right way. We would need to check if snprintf is available and if it is
C99 complient and if not use the replacement.

I had a lengthy discussion with the php group on that but i did
not get any answer at last. This might be the case because my
first worst assumptions were wrong for most systems.

In fact i could commit detection code and corect replacement code
but will do only when receiving a go from the group.

regards
marcus

At 23:31 16.08.2002, Dan Kalowsky wrote:
Yes, that is correct, bug #1298 (it's existed for a LONG time).

The user is having some difficulty compiling the Zend libraries for 4.2.2.
Mainly it seems that snprintf is turning up as an unresolved symbol.
I asked him to grep through the /usr/include looking for it, and the
result was nothing.

Looking through the code I see PHP has it's own snprintf implementation,
and that should suffice.  Apparently zend_API.c though doesn't notice it.
His fix was to place #include php.h inside the file, and everything
worked fine.

Does anyone have any more insight into this that they might be able to
share?

 ---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~dank   a little more action.
[EMAIL PROTECTED]   - A Little Less Conversation,
[EMAIL PROTECTED]Elvis Presley


--
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] Tru64, snprintf and bug #1298

2002-08-16 Thread Dan Kalowsky

Well it's starting to sound like it might be necessary to do this.  While
nohn's compiler is working, it seems that at least one other Tru64 person
is having difficulty.

Looking at the influx of bugs as well, I'm wondering if Tru64 is going to
be more of a problem for the project as whole... or if it's just 64-bit
arch's in the end.

On Sat, 17 Aug 2002, Marcus [iso-8859-1] Börger wrote:

 First of all the internal replacement of snprintf fails if size is 1 or 0.
 Second it is not C99 complient and third we do not include it the
 right way. We would need to check if snprintf is available and if it is
 C99 complient and if not use the replacement.

 I had a lengthy discussion with the php group on that but i did
 not get any answer at last. This might be the case because my
 first worst assumptions were wrong for most systems.

 In fact i could commit detection code and corect replacement code
 but will do only when receiving a go from the group.

 regards
 marcus

 At 23:31 16.08.2002, Dan Kalowsky wrote:
 Yes, that is correct, bug #1298 (it's existed for a LONG time).
 
 The user is having some difficulty compiling the Zend libraries for 4.2.2.
 Mainly it seems that snprintf is turning up as an unresolved symbol.
 I asked him to grep through the /usr/include looking for it, and the
 result was nothing.
 
 Looking through the code I see PHP has it's own snprintf implementation,
 and that should suffice.  Apparently zend_API.c though doesn't notice it.
 His fix was to place #include php.h inside the file, and everything
 worked fine.
 
 Does anyone have any more insight into this that they might be able to
 share?
 
  ---
 Dan KalowskyA little less conversation,
 http://www.deadmime.org/~dank   a little more action.
 [EMAIL PROTECTED]   - A Little Less Conversation,
 [EMAIL PROTECTED]Elvis Presley
 
 
 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, visit: http://www.php.net/unsub.php




---
Dan KalowskyA little less conversation,
http://www.deadmime.org/~danka little more action.
[EMAIL PROTECTED]- A Little Less Conversation,
[EMAIL PROTECTED]Elvis Presley


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




Re: [PHP-DEV] Mail-Header in bug-list

2002-07-26 Thread Joerg Behrens

- Original Message -
From: Georg Richter [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, July 26, 2002 11:04 PM
Subject: [PHP-DEV] Mail-Header in bug-list


 Hi

 would it be possible to revert the headers, or put the status at the end
of
 the subject?! Its impossible to read the subjects in your mailclient, even
if
 you use a terminal.

+1

with best regards
Joerg Behrens



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




Re: [PHP-DEV] Re: Switching zlib.output_compression, bug #16109

2002-06-25 Thread Stefan Roehrich

On 2002-06-25 09:36:20, Yasuo Ohgaki wrote:
 Yasuo Ohgaki wrote:
 I would suggest turn off compression for image.
 I mean turn off compression manually.
 As you already know, turning on and off by header(mime-type)
 does not work always, thus it's confusing.

Yes, but we need some kind of detection in order to disable it for PHP
internally generated images like the PHP/Zend logos used by
phpinfo(). Or we have to switch compression off there.

  Stefan

-- 
Stefan Röhrich   [EMAIL PROTECTED], [EMAIL PROTECTED]
 http://www.roehri.ch/~sr/

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




RE: [PHP-DEV] Re: Switching zlib.output_compression, bug #16109

2002-06-25 Thread Jaime Bozza

Personally, I don't really care to have compression turned off
automatically for images.  I'd like to be able to make that choice
myself.  For the browsers that work correctly, an uncompressed generated
image will still be able to take advantage of zlib compression.

I *DO* like the ability to be able to ini_set (or turn off some other
way) the zlib.output_compression switch.  That way, if I want to turn
off compression for some reason, I can just use the switch.

FYI, Netscape doesn't just have problems with images.  Netscape also
doesn't properly render compressed ILAYERs.  On my site, I have to
disable HTML (For Netscape) that is rendered in an ILAYER.

While the bugs in Netscape aren't necessarily PHP's problem, it really
would be nice to be able to turn off compression in cases where we have
to, *because* of the browser bugs.  The choice of using .htaccess
complicates something that should be easily tunable from within the
script.


Jaime Bozza


-Original Message-
From: Stefan Roehrich [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, June 25, 2002 8:19 AM
To: Yasuo Ohgaki
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Re: Switching zlib.output_compression, bug #16109


On 2002-06-25 09:36:20, Yasuo Ohgaki wrote:
 Yasuo Ohgaki wrote:
 I would suggest turn off compression for image.
 I mean turn off compression manually.
 As you already know, turning on and off by header(mime-type)
 does not work always, thus it's confusing.

Yes, but we need some kind of detection in order to disable it for PHP
internally generated images like the PHP/Zend logos used by
phpinfo(). Or we have to switch compression off there.

  Stefan

-- 
Stefan Röhrich   [EMAIL PROTECTED], [EMAIL PROTECTED]
 http://www.roehri.ch/~sr/

-- 
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] zlib double free bug and php

2002-06-05 Thread Markus Fischer

Hi,

PHP is as vulnerable as it is the libz of your system. PHP
does not include zlib, it links against it which means it has
already to be on your system. It is up to you to have the
proper libz on your system, PHP just links against it. That's
it.

- Markus

On Wed, Jun 05, 2002 at 03:39:55PM -0400, Lenny Miceli wrote : 
 Sorry to post here but I've received no response on the php-general list.  I
 posted the following to that list a couple days ago and I was wondering if
 anyone on this list can help me.  Thank you for your time.Lenny
 
 I've tried to search the archives/bug reports/faq's and didn't find any
 definitive answers on the zlib Double Free Bug CERT's Advisory CA-2002-07
 issue.  Even though I didn't compile php with the --with-zlib option when I
 run strings against the php library I still see zlib information.  For
 example:
 
  strings libphp4.a | grep -i zlib
 Request error: class file/memory mismatch
 Zlib
 
 So Zlib is still in the libphp4.a library.  So does this mean that I could
 possibly still be vulnerable to the zlib Double Free Bug?
 
 Also, if I DO need to compile php with the --with-zlib option I assume
 I will also need to give it the --with-zlib-dir option.  I assume if
 that zlib install directory does NOT have the bug, then I would be safe
 from it.  I'm asking since I know there's the ext/zlib directory under
 the php source directory (well at least php v4.0.6) and I'm not sure if
 the bug exists somewhere in those files.
 
 Thanks for any help you can give me on those 2 questions.
 
 Please mail me directly since I'm not on this list.
 
 Thanks for your time and help,
   Lenny Miceli
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, visit: http://www.php.net/unsub.php

-- 
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
Did I help you?http://guru.josefine.at/wish_en
Konnte ich helfen? http://guru.josefine.at/wish_de

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




Re: [PHP-DEV] zlib double free bug and php

2002-06-05 Thread Stefan Roehrich

Hello!

On 2002-06-05 15:39:55, Lenny Miceli wrote:
 issue.  Even though I didn't compile php with the --with-zlib option when I
 run strings against the php library I still see zlib information.  For

Maybe zlib is used by another library which PHP uses (e.g. some
graphic library, MySQL, ...).

 So Zlib is still in the libphp4.a library.  So does this mean that I could
 possibly still be vulnerable to the zlib Double Free Bug?

If you linked against a vulnerable zlib.

 Also, if I DO need to compile php with the --with-zlib option I assume
 I will also need to give it the --with-zlib-dir option.  I assume if

It isn't needed, otherwise PHP tries to find zlib.

 that zlib install directory does NOT have the bug, then I would be safe
 from it.  I'm asking since I know there's the ext/zlib directory under
 the php source directory (well at least php v4.0.6) and I'm not sure if
 the bug exists somewhere in those files.

The bug was in the zlib library, not in any file distributed with
PHP. If you link against a new zlib version you should be safe (if you
built PHP with a shared zlib library it's enough to update this
library, you don't have to rebuild PHP, but check with phpinfo() to
which version PHP is actually linked after the update).

You can use phpinfo() to see to which zlib version PHP is linked,
1.1.4 should be safe (but some systems use patched version of 1.1.3,
which are safe, but don't show a higher version number (bare 1.1.3 is
vulnerable)).

  Stefan

-- 
Stefan Röhrich   [EMAIL PROTECTED], [EMAIL PROTECTED]
 http://www.roehri.ch/~sr/

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




Re: [PHP-DEV] [PATCH] Fix for bug 16888

2002-05-17 Thread Joseph Tate

We'll try this again.  Here's the patch in a .txt file.

- Original Message -
From: Christian Stocker [EMAIL PROTECTED]
To: Joseph Tate [EMAIL PROTECTED]
Cc: Php-Dev List [EMAIL PROTECTED]
Sent: Thursday, May 16, 2002 7:23 PM
Subject: Re: [PHP-DEV] [PATCH] Fix for bug 16888


 On Thu, 16 May 2002, Joseph Tate wrote:

  The following fixes bug 16888 so that Apache and IIS no longer crash on
  Windows when using the domxml extension with more than 128 nodes.  See
  http://bugs.php.net/bug.php?id=16888 for details.
 
  Will the memory leak gurus please have a go at this and let me know what
  problems arise?  Also, please test on non Win platforms to make sure
that no
  functionality is lost.

 i certainly will (but i'm not the memory leak guru :) ), but the patch
 didn't make it through the mailing list. can you put it somewhere online?
 or send it to me personally, i can put it then on my webserver.

 chregu


 --
 nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich
 pho...+41  1 451 6021  www...http://phant.ch/chregu
 mob...+41 76 561 8860  [EMAIL PROTECTED]
 wor...+41  1 240 5670  gpg...0x5CE1DECB


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


Index: php_domxml.c
===
RCS file: /repository/php4/ext/domxml/php_domxml.c,v
retrieving revision 1.151
diff -u -r1.151 php_domxml.c
--- php_domxml.c16 May 2002 21:59:24 -  1.151
+++ php_domxml.c17 May 2002 09:04:35 -
@@ -577,12 +577,11 @@
 static void php_free_xml_node(zend_rsrc_list_entry *rsrc TSRMLS_DC)
 {
xmlNodePtr node = (xmlNodePtr) rsrc-ptr;
-
-   if (node) {
-   zval *wrapper = dom_object_get_data(node);
-   if (wrapper)
-   zval_ptr_dtor(wrapper);
-   }
+
+   node_wrapper_dtor(node);
+   //Should add a test here to make sure that refcount is 0 before setting to 
+null,
+   //and should move it to node_wrapper_dtor();
+   dom_object_set_data(node, NULL);
 }
 
 



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


Re: [PHP-DEV] [PATCH] Fix for bug 16888

2002-05-16 Thread Christian Stocker

On Thu, 16 May 2002, Joseph Tate wrote:

 The following fixes bug 16888 so that Apache and IIS no longer crash on
 Windows when using the domxml extension with more than 128 nodes.  See
 http://bugs.php.net/bug.php?id=16888 for details.

 Will the memory leak gurus please have a go at this and let me know what
 problems arise?  Also, please test on non Win platforms to make sure that no
 functionality is lost.

i certainly will (but i'm not the memory leak guru :) ), but the patch
didn't make it through the mailing list. can you put it somewhere online?
or send it to me personally, i can put it then on my webserver.

chregu


-- 
nam...christian stockeradr...bremgartnerstr. 66, ch-8003 zurich
pho...+41  1 451 6021  www...http://phant.ch/chregu
mob...+41 76 561 8860  [EMAIL PROTECTED]
wor...+41  1 240 5670  gpg...0x5CE1DECB


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




RE: [PHP-DEV] zend questions and bug #15333

2002-04-09 Thread Rose, Billy

Is this using the Microsoft libraries? If so, I have encountered similar
string function problems while creating an NT service. In the MS libs,
strings are handled as 32 bit integers with any odd bytes masked off at the
end of the string. The rep counter increments 4 times per iteration until
odd bytes are encountered. I worked around this by writing my own string
copy function.

Billy Rose 
[EMAIL PROTECTED]

 -Original Message-
 From: Joseph Tate [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, April 09, 2002 1:41 PM
 To: Php-Dev List
 Subject: [PHP-DEV] zend questions and bug #15333
 
 
 http://bugs.php.net/15333
 
 I've narrowed down the problem, but can't seem to get 
 anywhere with it.
 
 The state of the server when the problem occurrs:
 
 All serviceable threads have been killed or have timed out.
 A request is received prompting the spawning of a new thread.
 The new thread then goes through and copies the 
 global_constants_table, but
 that has been corrupted somewhere causing an access violation 
 when trying to
 dereference uninitialized memory.
 
 This happens every time the server has been idle for ~10 minutes after
 serving up php pages.
 
 Here are my questions that I haven't been able to track down 
 yet.  Hopefully
 someone can save me some time.
 
 1.What code is executed when a thread times out?  
 zend_shutdown never seems
 to run (or at least my breakpoints there never fire).
 
 2.It appears that global_constants_table is not global 
 nor constant, each
 thread has a separate copy.  Why is this the case?  And if it 
 is meant to
 be, where is the original global_constants_table.  What could 
 be modifying
 it so that it cannot be copied when a new thread is started?
 
 3.Where would be a good place to start to find the 
 answers to the zend
 questions that I have as I track this down.
 
 
 -- 
 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] zend questions and bug #15333

2002-04-09 Thread Rose, Billy

Forgot to mention, the algorithm in the MS lib is what is faulty. It
overruns the buffer at times.

Billy Rose 
[EMAIL PROTECTED]

 -Original Message-
 From: Joseph Tate [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, April 09, 2002 1:41 PM
 To: Php-Dev List
 Subject: [PHP-DEV] zend questions and bug #15333
 
 
 http://bugs.php.net/15333
 
 I've narrowed down the problem, but can't seem to get 
 anywhere with it.
 
 The state of the server when the problem occurrs:
 
 All serviceable threads have been killed or have timed out.
 A request is received prompting the spawning of a new thread.
 The new thread then goes through and copies the 
 global_constants_table, but
 that has been corrupted somewhere causing an access violation 
 when trying to
 dereference uninitialized memory.
 
 This happens every time the server has been idle for ~10 minutes after
 serving up php pages.
 
 Here are my questions that I haven't been able to track down 
 yet.  Hopefully
 someone can save me some time.
 
 1.What code is executed when a thread times out?  
 zend_shutdown never seems
 to run (or at least my breakpoints there never fire).
 
 2.It appears that global_constants_table is not global 
 nor constant, each
 thread has a separate copy.  Why is this the case?  And if it 
 is meant to
 be, where is the original global_constants_table.  What could 
 be modifying
 it so that it cannot be copied when a new thread is started?
 
 3.Where would be a good place to start to find the 
 answers to the zend
 questions that I have as I track this down.
 
 
 -- 
 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] zend questions and bug #15333

2002-04-09 Thread Joseph Tate

zend_strndup is a php implementation.  It does not use the strndup function
available through MS's library.  The problem occurs because a length of
100 or more is passed in, signifying to me that the source of that
length has become corrupted or not initialized.  I've traced that back to
the global_constants_table structure.  I no longer get the specific error
mentioned in the bug report, but get an error in the same location under the
same circumstances.  My error looks like the following:

The HTTP server encountered an unhandled exception while processing the
ISAPI Application '
msvcrt!memcpy + 0x33
php4ts!zend_strndup + 0x38
php4ts!zend_get_extension + 0xA0
php4ts!zend_hash_copy + 0x7B
php4ts!zend_get_extension + 0xFB
php4ts!zend_print_zval_r_ex + 0x999
php4ts!ts_resource_ex + 0x21F
php4ts!ts_resource_ex + 0x98
php4isapi!HttpExtensionProc + 0x37
wam + 0x7A91
wam + 0x8634
RPCRT4!NdrServerInitialize + 0x45B
RPCRT4!NdrStubCall2 + 0x1A5
RPCRT4!CStdStubBuffer_Invoke + 0x82
ole32!StgGetIFillLockBytesOnFile + 0xA270
ole32!StgGetIFillLockBytesOnFile + 0xA21F
ole32!CoImpersonateClient + 0x1B8
 + 0xFF6C8BE0
 + 0x1132AE13
'.

Of course I'm using the Release_TSDbg version of php4isapi rather than a
release, so that's why I have a stack trace.  All of this is with the
current PHP_4_2_0 release branch.

Joseph

 -Original Message-
 From: Rose, Billy [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, April 09, 2002 2:54 PM
 To: 'Joseph Tate'; Php-Dev List
 Subject: RE: [PHP-DEV] zend questions and bug #15333


 Forgot to mention, the algorithm in the MS lib is what is faulty. It
 overruns the buffer at times.

 Billy Rose
 [EMAIL PROTECTED]

  -Original Message-
  From: Joseph Tate [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, April 09, 2002 1:41 PM
  To: Php-Dev List
  Subject: [PHP-DEV] zend questions and bug #15333
 
 
  http://bugs.php.net/15333
 
  I've narrowed down the problem, but can't seem to get
  anywhere with it.
 
  The state of the server when the problem occurrs:
 
  All serviceable threads have been killed or have timed out.
  A request is received prompting the spawning of a new thread.
  The new thread then goes through and copies the
  global_constants_table, but
  that has been corrupted somewhere causing an access violation
  when trying to
  dereference uninitialized memory.
 
  This happens every time the server has been idle for ~10 minutes after
  serving up php pages.
 
  Here are my questions that I haven't been able to track down
  yet.  Hopefully
  someone can save me some time.
 
  1.  What code is executed when a thread times out?
  zend_shutdown never seems
  to run (or at least my breakpoints there never fire).
 
  2.  It appears that global_constants_table is not global
  nor constant, each
  thread has a separate copy.  Why is this the case?  And if it
  is meant to
  be, where is the original global_constants_table.  What could
  be modifying
  it so that it cannot be copied when a new thread is started?
 
  3.  Where would be a good place to start to find the
  answers to the zend
  questions that I have as I track this down.
 
 
  --
  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] zend questions and bug #15333

2002-04-09 Thread Rose, Billy

In your stack dump, the function call that bombed was memcpy in the MS lib.
Looking at the source in zend_alloc.c, I find that the lib's memcpy function
is used. The way I finally tracked down my problem was tedious as hell, but
I put the MS debug macro just before the function that was failing (in this
case zend_strndup). Then I single stepped into the MS function that was
failing. This method was required because I was running a service. I bet if
you write an adhoc my_memcpy function in C and byte for byte copy over the
string, the problem goes away. memcpy uses the same 32 bit algorothm as the
string functions. I sent in a bug report to MS about a year ago, but was
blown off (swept under the rug rather perhaps?). The algorithm seems to blow
up only under weird circumstances.

Billy Rose 
[EMAIL PROTECTED]

 -Original Message-
 From: Joseph Tate [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, April 09, 2002 2:05 PM
 To: Rose, Billy; Php-Dev List
 Subject: RE: [PHP-DEV] zend questions and bug #15333
 
 
 zend_strndup is a php implementation.  It does not use the 
 strndup function
 available through MS's library.  The problem occurs because a 
 length of
 100 or more is passed in, signifying to me that the source of that
 length has become corrupted or not initialized.  I've traced 
 that back to
 the global_constants_table structure.  I no longer get the 
 specific error
 mentioned in the bug report, but get an error in the same 
 location under the
 same circumstances.  My error looks like the following:
 
 The HTTP server encountered an unhandled exception while 
 processing the
 ISAPI Application '
 msvcrt!memcpy + 0x33
 php4ts!zend_strndup + 0x38
 php4ts!zend_get_extension + 0xA0
 php4ts!zend_hash_copy + 0x7B
 php4ts!zend_get_extension + 0xFB
 php4ts!zend_print_zval_r_ex + 0x999
 php4ts!ts_resource_ex + 0x21F
 php4ts!ts_resource_ex + 0x98
 php4isapi!HttpExtensionProc + 0x37
 wam + 0x7A91
 wam + 0x8634
 RPCRT4!NdrServerInitialize + 0x45B
 RPCRT4!NdrStubCall2 + 0x1A5
 RPCRT4!CStdStubBuffer_Invoke + 0x82
 ole32!StgGetIFillLockBytesOnFile + 0xA270
 ole32!StgGetIFillLockBytesOnFile + 0xA21F
 ole32!CoImpersonateClient + 0x1B8
  + 0xFF6C8BE0
  + 0x1132AE13
 '.
 
 Of course I'm using the Release_TSDbg version of php4isapi 
 rather than a
 release, so that's why I have a stack trace.  All of this is with the
 current PHP_4_2_0 release branch.
 
 Joseph
 
  -Original Message-
  From: Rose, Billy [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, April 09, 2002 2:54 PM
  To: 'Joseph Tate'; Php-Dev List
  Subject: RE: [PHP-DEV] zend questions and bug #15333
 
 
  Forgot to mention, the algorithm in the MS lib is what is faulty. It
  overruns the buffer at times.
 
  Billy Rose
  [EMAIL PROTECTED]
 
   -Original Message-
   From: Joseph Tate [mailto:[EMAIL PROTECTED]]
   Sent: Tuesday, April 09, 2002 1:41 PM
   To: Php-Dev List
   Subject: [PHP-DEV] zend questions and bug #15333
  
  
   http://bugs.php.net/15333
  
   I've narrowed down the problem, but can't seem to get
   anywhere with it.
  
   The state of the server when the problem occurrs:
  
   All serviceable threads have been killed or have timed out.
   A request is received prompting the spawning of a new thread.
   The new thread then goes through and copies the
   global_constants_table, but
   that has been corrupted somewhere causing an access violation
   when trying to
   dereference uninitialized memory.
  
   This happens every time the server has been idle for ~10 
 minutes after
   serving up php pages.
  
   Here are my questions that I haven't been able to track down
   yet.  Hopefully
   someone can save me some time.
  
   1.What code is executed when a thread times out?
   zend_shutdown never seems
   to run (or at least my breakpoints there never fire).
  
   2.It appears that global_constants_table is not global
   nor constant, each
   thread has a separate copy.  Why is this the case?  And if it
   is meant to
   be, where is the original global_constants_table.  What could
   be modifying
   it so that it cannot be copied when a new thread is started?
  
   3.Where would be a good place to start to find the
   answers to the zend
   questions that I have as I track this down.
  
  
   --
   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] zend questions and bug #15333

2002-04-09 Thread Joseph Tate

I've looked at it in the debugger immediately before the access violation
and have found that both the pointer to the char* to be copied and the
length are garbage, so it's not the lib.

 -Original Message-
 From: Rose, Billy [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, April 09, 2002 3:29 PM
 To: 'Joseph Tate'; Rose, Billy; Php-Dev List
 Subject: RE: [PHP-DEV] zend questions and bug #15333


 In your stack dump, the function call that bombed was memcpy in
 the MS lib.
 Looking at the source in zend_alloc.c, I find that the lib's
 memcpy function
 is used. The way I finally tracked down my problem was tedious as
 hell, but
 I put the MS debug macro just before the function that was
 failing (in this
 case zend_strndup). Then I single stepped into the MS function that was
 failing. This method was required because I was running a
 service. I bet if
 you write an adhoc my_memcpy function in C and byte for byte copy over the
 string, the problem goes away. memcpy uses the same 32 bit
 algorothm as the
 string functions. I sent in a bug report to MS about a year ago, but was
 blown off (swept under the rug rather perhaps?). The algorithm
 seems to blow
 up only under weird circumstances.

 Billy Rose
 [EMAIL PROTECTED]

  -Original Message-
  From: Joseph Tate [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, April 09, 2002 2:05 PM
  To: Rose, Billy; Php-Dev List
  Subject: RE: [PHP-DEV] zend questions and bug #15333
 
 
  zend_strndup is a php implementation.  It does not use the
  strndup function
  available through MS's library.  The problem occurs because a
  length of
  100 or more is passed in, signifying to me that the source of that
  length has become corrupted or not initialized.  I've traced
  that back to
  the global_constants_table structure.  I no longer get the
  specific error
  mentioned in the bug report, but get an error in the same
  location under the
  same circumstances.  My error looks like the following:
 
  The HTTP server encountered an unhandled exception while
  processing the
  ISAPI Application '
  msvcrt!memcpy + 0x33
  php4ts!zend_strndup + 0x38
  php4ts!zend_get_extension + 0xA0
  php4ts!zend_hash_copy + 0x7B
  php4ts!zend_get_extension + 0xFB
  php4ts!zend_print_zval_r_ex + 0x999
  php4ts!ts_resource_ex + 0x21F
  php4ts!ts_resource_ex + 0x98
  php4isapi!HttpExtensionProc + 0x37
  wam + 0x7A91
  wam + 0x8634
  RPCRT4!NdrServerInitialize + 0x45B
  RPCRT4!NdrStubCall2 + 0x1A5
  RPCRT4!CStdStubBuffer_Invoke + 0x82
  ole32!StgGetIFillLockBytesOnFile + 0xA270
  ole32!StgGetIFillLockBytesOnFile + 0xA21F
  ole32!CoImpersonateClient + 0x1B8
   + 0xFF6C8BE0
   + 0x1132AE13
  '.
 
  Of course I'm using the Release_TSDbg version of php4isapi
  rather than a
  release, so that's why I have a stack trace.  All of this is with the
  current PHP_4_2_0 release branch.
 
  Joseph
 
   -Original Message-
   From: Rose, Billy [mailto:[EMAIL PROTECTED]]
   Sent: Tuesday, April 09, 2002 2:54 PM
   To: 'Joseph Tate'; Php-Dev List
   Subject: RE: [PHP-DEV] zend questions and bug #15333
  
  
   Forgot to mention, the algorithm in the MS lib is what is faulty. It
   overruns the buffer at times.
  
   Billy Rose
   [EMAIL PROTECTED]
  
-Original Message-
From: Joseph Tate [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 09, 2002 1:41 PM
To: Php-Dev List
Subject: [PHP-DEV] zend questions and bug #15333
   
   
http://bugs.php.net/15333
   
I've narrowed down the problem, but can't seem to get
anywhere with it.
   
The state of the server when the problem occurrs:
   
All serviceable threads have been killed or have timed out.
A request is received prompting the spawning of a new thread.
The new thread then goes through and copies the
global_constants_table, but
that has been corrupted somewhere causing an access violation
when trying to
dereference uninitialized memory.
   
This happens every time the server has been idle for ~10
  minutes after
serving up php pages.
   
Here are my questions that I haven't been able to track down
yet.  Hopefully
someone can save me some time.
   
1.  What code is executed when a thread times out?
zend_shutdown never seems
to run (or at least my breakpoints there never fire).
   
2.  It appears that global_constants_table is not global
nor constant, each
thread has a separate copy.  Why is this the case?  And if it
is meant to
be, where is the original global_constants_table.  What could
be modifying
it so that it cannot be copied when a new thread is started?
   
3.  Where would be a good place to start to find the
answers to the zend
questions that I have as I track this down.
   
   
--
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

Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]

2002-03-24 Thread Markus Fischer

Why do you think apache gets a segfault?

The only thing is the the 'domainname' key is missing from
the hash although it should display the content of
__domainname (on non-bsd systems)

I'm willing to fix it if someone comes up with a proper patch
that also honors BSD. It's not very critical I think (until I
miss the obvious).

- Markus

On Sun, Mar 24, 2002 at 12:16:41PM +0100, Vergoz Michael (SYSDOOR) wrote : 
 

 Date: Sun, 24 Mar 2002 12:03:42 +0100
 From: Vergoz Michael (SYSDOOR) [EMAIL PROTECTED]
 Subject: posix_uname another bug @^|[@#\@^#~@{[?
 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214
 To: php-qa [EMAIL PROTECTED]
 From - Sun Mar 24 12:03:43 2002
 X-Mozilla-Status2: 
 
 refere include file : sys/utsname.h !
 You can see if the macro __USE_GNU is set the char returned are 
 'domainname' else the char are '__domainname' #@\[@~\
 You know this function can do a apache segfault ?!
 Becarful cuz domainename doesn't exist on freebsd !
 
 there is the current (PHP-4.2.0RC1) code on : ext/posix/posix.c
 
 /* {{{ proto array posix_uname(void)
   Get system name (POSIX.1, 4.4.1) */
 PHP_FUNCTION(posix_uname)
 {
struct utsname u;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
return;
 
if (uname(u)  0) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}
 
if (array_init(return_value) == FAILURE) {
// TODO: Should we issue a warning here so we don't have ambiguity
// with the above return value ?
RETURN_FALSE;
}
 
add_assoc_string(return_value, sysname,  u.sysname,  1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release,  u.release,  1);
add_assoc_string(return_value, version,  u.version,  1);
add_assoc_string(return_value, machine,  u.machine,  1);
 #ifdef _GNU_SOURCE/* i'm okay */
add_assoc_string(return_value, domainname, u.domainname, 1); /* - 
 {|^@#\|^[#\ */
 #endif
 }
 /* }}} */
 
 /*Fixed 
 code--*/
 
 /* {{{ proto array posix_uname(void)
   Get system name (POSIX.1, 4.4.1) */
 PHP_FUNCTION(posix_uname)
 {
struct utsname u;
 
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
return;
 
if (uname(u)  0) {
POSIX_G(last_error) = errno;
RETURN_FALSE;
}
 
if (array_init(return_value) == FAILURE) {
// TODO: Should we issue a warning here so we don't have ambiguity
// with the above return value ?
RETURN_FALSE;
}
 
add_assoc_string(return_value, sysname,  u.sysname,  1);
add_assoc_string(return_value, nodename, u.nodename, 1);
add_assoc_string(return_value, release,  u.release,  1);
add_assoc_string(return_value, version,  u.version,  1);
add_assoc_string(return_value, machine,  u.machine,  1);
 #ifdef _GNU_SOURCE
#ifdef __USE_GNU
add_assoc_string(return_value, domainname, u.domainname, 1);
#else
add_assoc_string(return_value, domainname, u.__domainname, 1);
#endif
 #endif
 }
 /* }}} */
 
 

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

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc

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




Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]

2002-03-24 Thread Vergoz Michael (SYSDOOR)

have you reveiv the pgsql.c optimization code ?
(is nothing to fix le utsname ;))

another question : how to become a php developer ?

- Original Message -
From: Markus Fischer [EMAIL PROTECTED]
To: Vergoz Michael (SYSDOOR) [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, March 24, 2002 12:51 PM
Subject: Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]


 Why do you think apache gets a segfault?
sorry not segfault but compilation problem ;)

 The only thing is the the 'domainname' key is missing from
 the hash although it should display the content of
 __domainname (on non-bsd systems)

 I'm willing to fix it if someone comes up with a proper patch
 that also honors BSD. It's not very critical I think (until I
 miss the obvious).

 - Markus

 On Sun, Mar 24, 2002 at 12:16:41PM +0100, Vergoz Michael (SYSDOOR) wrote :
 

  Date: Sun, 24 Mar 2002 12:03:42 +0100
  From: Vergoz Michael (SYSDOOR) [EMAIL PROTECTED]
  Subject: posix_uname another bug @^|[@#\@^#~@{[?
  User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8)
Gecko/20020214
  To: php-qa [EMAIL PROTECTED]
  From - Sun Mar 24 12:03:43 2002
  X-Mozilla-Status2: 
 
  refere include file : sys/utsname.h !
  You can see if the macro __USE_GNU is set the char returned are
  'domainname' else the char are '__domainname' #@\[@~\
  You know this function can do a apache segfault ?!
  Becarful cuz domainename doesn't exist on freebsd !
 
  there is the current (PHP-4.2.0RC1) code on : ext/posix/posix.c
 
  /* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
  PHP_FUNCTION(posix_uname)
  {
 struct utsname u;
 
 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
 return;
 
 if (uname(u)  0) {
 POSIX_G(last_error) = errno;
 RETURN_FALSE;
 }
 
 if (array_init(return_value) == FAILURE) {
 // TODO: Should we issue a warning here so we don't have
ambiguity
 // with the above return value ?
 RETURN_FALSE;
 }
 
 add_assoc_string(return_value, sysname,  u.sysname,  1);
 add_assoc_string(return_value, nodename, u.nodename, 1);
 add_assoc_string(return_value, release,  u.release,  1);
 add_assoc_string(return_value, version,  u.version,  1);
 add_assoc_string(return_value, machine,  u.machine,  1);
  #ifdef _GNU_SOURCE/* i'm okay */
 add_assoc_string(return_value, domainname, u.domainname, 1); /* -
  {|^@#\|^[#\ */
  #endif
  }
  /* }}} */
 
  /*Fixed
  code--*/
 
  /* {{{ proto array posix_uname(void)
Get system name (POSIX.1, 4.4.1) */
  PHP_FUNCTION(posix_uname)
  {
 struct utsname u;
 
 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, ) == FAILURE)
 return;
 
 if (uname(u)  0) {
 POSIX_G(last_error) = errno;
 RETURN_FALSE;
 }
 
 if (array_init(return_value) == FAILURE) {
 // TODO: Should we issue a warning here so we don't have
ambiguity
 // with the above return value ?
 RETURN_FALSE;
 }
 
 add_assoc_string(return_value, sysname,  u.sysname,  1);
 add_assoc_string(return_value, nodename, u.nodename, 1);
 add_assoc_string(return_value, release,  u.release,  1);
 add_assoc_string(return_value, version,  u.version,  1);
 add_assoc_string(return_value, machine,  u.machine,  1);
  #ifdef _GNU_SOURCE
 #ifdef __USE_GNU
 add_assoc_string(return_value, domainname, u.domainname, 1);
 #else
 add_assoc_string(return_value, domainname, u.__domainname, 1);
 #endif
  #endif
  }
  /* }}} */
 
 

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

 --
 Please always Cc to me when replying to me on the lists.
 GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc



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




Re: [PHP-DEV] [Fwd: posix_uname another bug @^|[@#\@^#~@{[?]

2002-03-24 Thread Yasuo Ohgaki

Vergoz Michael wrote:
 have you reveiv the pgsql.c optimization code ?
 (is nothing to fix le utsname ;))

No. I didn't get any patch. Could mail me.

 
 another question : how to become a php developer ?

Submit sevral patches? then apply CVS account?

--
Yasuo Ohgaki


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




Re: [PHP-DEV] ZLib (double free) bug

2002-03-12 Thread Stefan Roehrich

On 2002-03-12 10:50:43, Andrey Hristov wrote:
 What about implementing in build process check for the version of
 the zlib library. If =1.1.3 to give error message that =1.1.4 is
 needed. 1.1.4 is at :

I already thought about that, but there are people or even whole linux
distributions (e.g. Debian), who are patching their zlib libraries
without using the whole 1.1.4, so their zlib version stays at 1.1.3,
but without the bug.

So we would to really test for this double free error, we can't rely
on the zlib version, if we don't want to break php build for this
platforms. But I think using this double free bug would be a little
bit of overkill for a configure script ...

  Stefan

-- 
Stefan Röhrich   [EMAIL PROTECTED], [EMAIL PROTECTED]
 http://www.roehri.ch/~sr/

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




Re: [PHP-DEV] ZLib (double free) bug

2002-03-12 Thread Andrey Hristov

Yeap. :(( the RH RPM is 1.1.3-25.7

 ftp://updates.redhat.com/7.2/en/os/i386/zlib-1.1.3 -25.7.i386.rpm

Andrey

- Original Message -
From: Stefan Roehrich [EMAIL PROTECTED]
To: Andrey Hristov [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, March 12, 2002 11:46 AM
Subject: Re: [PHP-DEV] ZLib (double free) bug


 On 2002-03-12 10:50:43, Andrey Hristov wrote:
  What about implementing in build process check for the version of
  the zlib library. If =1.1.3 to give error message that =1.1.4 is
  needed. 1.1.4 is at :

 I already thought about that, but there are people or even whole linux
 distributions (e.g. Debian), who are patching their zlib libraries
 without using the whole 1.1.4, so their zlib version stays at 1.1.3,
 but without the bug.

 So we would to really test for this double free error, we can't rely
 on the zlib version, if we don't want to break php build for this
 platforms. But I think using this double free bug would be a little
 bit of overkill for a configure script ...

   Stefan

 --
 Stefan Röhrich   [EMAIL PROTECTED], [EMAIL PROTECTED]
  http://www.roehri.ch/~sr/

 --
 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] ICONV patch for bug 14423

2002-03-03 Thread Derick Rethans

Hello,

attached is a fixed diff, it works on Linux now (RH 7.1).

Derick

On Sun, 3 Mar 2002, Dan Kalowsky wrote:

 I need a review bug #14423 (http://bugs.php.net/bug.php?id=14423edit=1)

 I think I've figured out what is wrong, but unfortunately I cannot do a
 buildconf on the machine I'm on currently (libtool is limited to 1.3, not
 1.4).

 So if someone can try this patch out and comment on any corrections for
 it, I'd appriciate it :)  You'll find the patch attached to the email.
 While this bug is limited to the FreeBSD platform, this patch will effect
 the building on all machines (alters the config.m4).  So if at least one
 other OS could test it out as well, I'd appriciate it.


 ---
 Dan Kalowsky  Tonight I think I'll walk alone.
 http://www.deadmime.org/~dank  I'll find soul as I go home.
 [EMAIL PROTECTED]  - Temptation, New Order


Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


? iconv.diff
Index: config.m4
===
RCS file: /repository/php4/ext/iconv/config.m4,v
retrieving revision 1.7
diff -u -r1.7 config.m4
--- config.m4   30 Nov 2001 18:59:38 -  1.7
+++ config.m4   3 Mar 2002 18:11:24 -
@@ -7,15 +7,27 @@
 
 if test $PHP_ICONV != no; then
 
+dnl This is a fix for why FreeBSD does not work with ICONV
+dnl It seems libtool checks for libiconv_open which only exists in
+dnl the giconv series of files under FreeBSD
+
+  ac_os_uname=`uname -s 2/dev/null`
+
+  if test $ac_os_uname = FreeBSD; then
+   lib_name=giconv
+  else
+   lib_name=iconv
+  fi
+
   for i in /usr /usr/local $PHP_ICONV; do
-test -r $i/include/iconv.h  ICONV_DIR=$i
+test -r $i/include/${lib_name}.h  ICONV_DIR=$i
   done
 
   if test -z $ICONV_DIR; then
 AC_MSG_ERROR(Please reinstall the iconv library.)
   fi
   
-  if test -f $ICONV_DIR/lib/libconv.a -o -f 
$ICONV_DIR/lib/libiconv.$SHLIB_SUFFIX_NAME ; then
+  if test -f $ICONV_DIR/lib/libconv.a -o -f 
+$ICONV_DIR/lib/lib${lib_name}.$SHLIB_SUFFIX_NAME ; then
 PHP_ADD_LIBRARY_WITH_PATH(iconv, $ICONV_DIR/lib, ICONV_SHARED_LIBADD)
 AC_CHECK_LIB(iconv, libiconv_open, [
AC_DEFINE(HAVE_ICONV, 1, [ ])
Index: php_iconv.h
===
RCS file: /repository/php4/ext/iconv/php_iconv.h,v
retrieving revision 1.9
diff -u -r1.9 php_iconv.h
--- php_iconv.h 13 Dec 2001 14:31:16 -  1.9
+++ php_iconv.h 3 Mar 2002 18:11:24 -
@@ -26,8 +26,9 @@
 #define PHP_ICONV_API
 #endif
 
+#if HAVE_ICONV
 extern zend_module_entry iconv_module_entry;
-#define phpext_iconv_ptr iconv_module_entry
+#define iconv_module_ptr iconv_module_entry
 
 PHP_MINIT_FUNCTION(miconv);
 PHP_MSHUTDOWN_FUNCTION(miconv);
@@ -53,6 +54,14 @@
 #define ICONV_INPUT_ENCODING ISO-8859-1 
 #define ICONV_OUTPUT_ENCODING ISO-8859-1
 #define ICONV_INTERNAL_ENCODING ISO-8859-1 
+
+#else
+
+#define iconv_module_ptr NULL
+
+#endif /* HAVE_ICONV */
+
+#define phpext_iconv_ptr iconv_module_ptr
 
 #endif /* PHP_ICONV_H */
 


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


Re: [PHP-DEV] ICONV patch for bug 14423

2002-03-03 Thread Dan Kalowsky

Um yeah, this is the patch I ment to send initially :)

If no comments/concerns are heard within 24 hours, you'll find this patch
in the cvs.

On Sun, 3 Mar 2002, Derick Rethans wrote:

 Hello,

 attached is a fixed diff, it works on Linux now (RH 7.1).

 Derick

 On Sun, 3 Mar 2002, Dan Kalowsky wrote:

  I need a review bug #14423 (http://bugs.php.net/bug.php?id=14423edit=1)
 
  I think I've figured out what is wrong, but unfortunately I cannot do a
  buildconf on the machine I'm on currently (libtool is limited to 1.3, not
  1.4).
 
  So if someone can try this patch out and comment on any corrections for
  it, I'd appriciate it :)  You'll find the patch attached to the email.
  While this bug is limited to the FreeBSD platform, this patch will effect
  the building on all machines (alters the config.m4).  So if at least one
  other OS could test it out as well, I'd appriciate it.
 
 
  ---
  Dan KalowskyTonight I think I'll walk alone.
  http://www.deadmime.org/~dankI'll find soul as I go home.
  [EMAIL PROTECTED]- Temptation, New Order
 

 Derick Rethans

 -
 PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
  SRM: Site Resource Manager - www.vl-srm.net
 -


---
Dan KalowskyTonight I think I'll walk alone.
http://www.deadmime.org/~dankI'll find soul as I go home.
[EMAIL PROTECTED]- Temptation, New Order


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




Re: [PHP-DEV] Re: [mfischer@php.net: Bug #12465 Updated: posix_* issuing Warnings, no error code.]

2002-03-01 Thread Edin Kadribasic

 My point was to remove the (not needed) php_error() calls
 completely and save the message(errorcode) in a variable so
 the user (developer) can decide himself if he wants to do
 something with the message or not.

 php_error() call's are, verbosely spoken, pain in the ass to
 catch ($php_errmsg global var?? no thanks). It would overal
 make more sense for this module to don't do any error output
 itself but provide a error string fetch function or so.

+1

Having posix_errno() which returns the error of the last message and
posix_strerror() which returns the description should be the way to go. In
addition it is consistent with the rest of posix functions.

Edin



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




Re: [PHP-DEV] socket_send() ...also a bug?

2002-02-16 Thread Markus Fischer

It's documented on
http://www.php.net/manual/en/zend.arguments.retrieval.php

It's a kind of promoting binary safety. Not the passed number
of parameter passed to zend_parse_parameters() is important
but what modifies are used to describe the parameters.

Since a string is not only meant to be characters from A-Z
but in fact can be anything including binary data, it's a
good idea [tm] to always get the point to the string AND it's
length and work with both when making further function calls
(if possible).

On Sat, Feb 16, 2002 at 03:08:06AM +0100, Richard Samar wrote : 
 
 
 Sean R. Bright wrote:
  
  len is the length of the buffer.  When 's' is specified in
  zend_parse_parameters, both the string and the number of characters
  are returned to the calling function.  In this case, len is the
  length of 'buf_len.'
 
 :-) oki, the given prototype ist wrong then. 
 
 could you post me an example. I dont understand 's'.
 
 thx
 
 best regards
 -moh
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Please always Cc to me when replying to me on the lists.
GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc

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




RE: [PHP-DEV] socket_send() ...also a bug?

2002-02-15 Thread Sean R. Bright

len is the length of the buffer.  When 's' is specified in
zend_parse_parameters, both the string and the number of characters
are returned to the calling function.  In this case, len is the
length of 'buf_len.'

 -Original Message-
 From: Richard Samar [mailto:[EMAIL PROTECTED]]
 Sent: Friday, February 15, 2002 8:27 PM
 To: Jason Greene
 Cc: [EMAIL PROTECTED]
 Subject: [PHP-DEV] socket_send() ...also a bug?
 
 
 I found something else about socket_send():
 
 proto: int socket_send(resource socket, string buf, int len, 
 int flags)
 4 parameters
 
 from the source: 
 
 if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, rsll, arg1,
 buf, buf_len, len, flags) == FAILURE)
 
 5 parameters? what is len?? please remove it. it doesnt makes sense
 to me.
 
 the system call send() doesnt have 5 parameters.
 
 best regards
 -moh
 
 -- 
 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] socket_send() ...also a bug?

2002-02-15 Thread Richard Samar



Sean R. Bright wrote:
 
 len is the length of the buffer.  When 's' is specified in
 zend_parse_parameters, both the string and the number of characters
 are returned to the calling function.  In this case, len is the
 length of 'buf_len.'

:-) oki, the given prototype ist wrong then. 

could you post me an example. I dont understand 's'.

thx

best regards
-moh

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




Re: [PHP-DEV] PHP 4.0.6 IMAP BUG

2001-12-20 Thread Jon Parise

On Thu, Dec 20, 2001 at 10:32:43AM +0100, Markus Fischer wrote:

 Glad I didn't, its a bug in ext/imap. Due the pointer
 juggling we're accidantly calling fs_free() on something
 which was never explicetely malloced. I've a patch here which
 takes care of this but I'm not too familiar with imap code.
 
Your patch looks sound enough, although I'm not very familiar
with that code, either.  I don't see any harm committing it to
the HEAD branch.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Information Technology (2001)
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] PHP 4.0.6 IMAP BUG

2001-12-20 Thread Markus Fischer

On Thu, Dec 20, 2001 at 02:26:26PM -0500, Jon Parise wrote : 
 On Thu, Dec 20, 2001 at 10:32:43AM +0100, Markus Fischer wrote:
 
  Glad I didn't, its a bug in ext/imap. Due the pointer
  juggling we're accidantly calling fs_free() on something
  which was never explicetely malloced. I've a patch here which
  takes care of this but I'm not too familiar with imap code.
  
 Your patch looks sound enough, although I'm not very familiar
 with that code, either.  I don't see any harm committing it to
 the HEAD branch.

Anton,

can you test the patch I mailed to you (and -dev) and see if
its ok?

- Markus

-- 
Please always Cc to me when replying to me on the lists.

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] PHP 4.0.6 IMAP BUG

2001-12-19 Thread Markus Fischer

Verified with latest CVS. No time do dig in right now, but note
the crash occurs in the imap library:

(gdb) bt
#0  0x40113bee in free () from /lib/libc.so.6
#1  0x40113ac3 in free () from /lib/libc.so.6
#2  0x402b4063 in fs_give () from /usr/lib/libc-client.so.2001
#3  0x4028f699 in zif_imap_mime_header_decode () from 
/home/mfischer/php4/lib/php/extensions/debug-non-zts-20010901/imap.so
#4  0x0813a1ba in execute (op_array=0x81bc244) at ./zend_execute.c:1598
#5  0x08113f69 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:810
#6  0x08061481 in php_execute_script (primary_file=0xb504) at main.c:1308
#7  0x0805eccf in main (argc=3, argv=0xb594) at cgi_main.c:753
#8  0x400be65f in __libc_start_main () from /lib/libc.so.6


- Markus

On Wed, Dec 19, 2001 at 06:35:11PM +0300, Kachalov Anton wrote : 
 If you try to run this lines:
 ?
 imap_mime_header_decode('[sisyphus] Re: 
?KOI8-R?B?7s/X2cog0MHU3iDQxdLFy8/EydLP18vJIA==?==?KOI8-R?B?xMzR?= mc');
 ?
 
 PHP will crash
 
 Rgds,
 Anton
 
 [EMAIL PROTECTED]
 http://www.altlinux.ru
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
Please always Cc to me when replying to me on the lists.

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] PHP 4.0.6 IMAP BUG

2001-12-19 Thread Jon Parise

On Wed, Dec 19, 2001 at 05:35:53PM +0100, Markus Fischer wrote:

 Verified with latest CVS. No time do dig in right now, but note
 the crash occurs in the imap library:
 
Please forward the test case and your backtrace to the c-client
mailing list:

http://www.washington.edu/imap/c-client-list.html

-- 
Jon Parise ([EMAIL PROTECTED])  .  Information Technology (2001)
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Bug #12737: index bug concerning 00 and 08

2001-08-14 Thread Adam Wright

0n defines octal representation (which is why 00 though 08 go 'wrong'). See
http://php.net/manual/en/language.types.integer.php

So, this isn't a bug in PHP.

adamw

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 14, 2001 11:03 AM
Subject: [PHP-DEV] Bug #12737: index bug concerning 00 and 08


 From: [EMAIL PROTECTED]
 Operating system: Linux 2.2.19 #10 SMP i686
 PHP version:  4.0.5
 PHP Bug Type: Arrays related
 Bug description:  index bug concerning 00 and 08

 Using 0 padded integers as index for an array:
 - does not work for 0 and 8
 - scrambles the order of the elements

 ---
 $a[00] = string0;
 $a[01] = string1;
 $a[02] = string2;
 $a[03] = string3;
 $a[04] = string4;
 $a[05] = string5;
 $a[06] = string6;
 $a[07] = string7;
 $a[08] = string8;
 $a[09] = string9;

 echo implode(;, $a);
 

 This yields:

 string9;string1;string2;string3;string4;string5;string6;string7
 --
 Edit bug report at: http://bugs.php.net/?id=12737edit=1


 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-DOC] Bug #10398 Updated: configuration chapter still has the old php 3 error_reporting values

2001-08-05 Thread Andy

ok, i'll change it to closed...

On Sun, 05 Aug 2001, Cynic wrote:
 Hi Egon.
 
 I checked the page, and it seems like it's been corrected 
 meanwhile. It now contains info for both PHP 3 and 4.
 
 The bug should be prolly closed, not bogusified.
 
 At 02:30 8/6/2001, [EMAIL PROTECTED] wrote the following:
 -- 
 On Sun, Aug 05, 2001 at 11:51:19PM -, [EMAIL PROTECTED] wrote:
  ID: 10398
  Updated by: andy
  Reported By: [EMAIL PROTECTED]
  Old Status: Open
  Status: Bogus
  Bug Type: Documentation problem
  Operating System: *
  PHP Version: 4.0.4pl1
  New Comment:
  
  status - bogus
  
 
 [...]
 
 Why? I know Hartmut very well, and he writes no nonsens on the bugs.list.
 Please reopen that bug.
 
 -Egon
 
 
 
 [EMAIL PROTECTED]
 -
 And the eyes of them both were opened and they saw that their files
 were world readable and writable, so they chmoded 600 their files.
 - Book of Installation chapt 3 sec 7 
 
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Is this a bug?

2001-07-20 Thread Andi Gutmans

At 11:47 AM 7/20/2001 +0200, Sebastian Bergmann wrote:
 ?php
 class foo {
 function bar() {
 print 'bar() calledbr';
 }
 }

 $foo = new foo();
 $bar = $foo;
 $method = 'bar';

 $foo-$method;   // does not work
 $bar-$method;   // does not work

This should be $foo-$method() and $bar-$method()

 call_user_method($method, $foo); // works
 call_user_method($method, $bar); // works
 ?

   I think this is a bug, and all four ways to invoke the method must
have worked at some time in the past (I tested with latest 4.0.7-dev
CVS on Win32), since PEAR uses the first/second method to invoke its
'emulated destructors'.

--
   Sebastian Bergmann Measure Traffic  Usability
   http://sebastian-bergmann.de/http://phpOpenTracker.de/

--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Is this a bug?

2001-07-20 Thread Sebastian Bergmann

Andi Gutmans wrote:
  $foo-$method;   // does not work
  $bar-$method;   // does not work
 
 This should be $foo-$method() and $bar-$method()

  Gotcha. This works fine.
  How could I forget the braces?

-- 
  Sebastian Bergmann Measure Traffic  Usability
  http://sebastian-bergmann.de/http://phpOpenTracker.de/

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Is this a bug?

2001-07-20 Thread Andi Gutmans

At 02:31 PM 7/20/2001 +0200, Sebastian Bergmann wrote:
Andi Gutmans wrote:
   $foo-$method;   // does not work
   $bar-$method;   // does not work
 
  This should be $foo-$method() and $bar-$method()

   Gotcha. This works fine.
   How could I forget the braces?

I don't quite understand. Why not write them? :)

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced

2001-06-20 Thread Brian Tanner

I want to chime in here.  The reason (IMHO) that they are asking you to test
the latest release is because you are reporting a symptom of a bigger
problem.

They *think* that they fixed the bigger problem.  However, the best way to
be *sure* (like you want) -- is to have people see if the symptoms are gone.
Instead of recreating every problem that people describe... they try to fix
the root cause, and see if all of the related problems go away.

Make sense?

-Brian




Amazing.  No report has been made that the bug has been resolved, yet you
have a burr up your butt to close out the problem anyway.  Great debugging
technique.  Truly professional.  Good to know PHP is in such good hands.

Yes, to answer your comment, I DO remember that I wrote that.  In fact, it's
basically a repeat of the same thing I wrote earlier, since you did not seem
to pay attention the first time.  Each time a point release is out, I check
it, as I--like many PHP users--would like to have the latest features and
bug fixes.  PHP totally kicks ass, but unfortunately there are some glitches
from time to time.

HOWEVER, a nightly CVS build is not considered by most to be a stable
release.  Ergo we have such things as RELEASE CANDIDATES.  PHP is now at
4.0.6 RC3 if memory recalls correctly.  However, this too is not a full
release.  RCs are basically like beta releases for those so inclined (and
with sufficient time) to be guinea pigs.  CVS nightly builds are for those
normally heavily involved, RCs are for those who want to help point out
flaws in the next release, and then actual point releases are what most
users obtain.

I apologize if I don't satisfy your sudden demand for people to jump at
testing your nightly builds or RCs.  But like many I actually have a job and
life that requires most of my time.  I gladly test full point releases, but
unfortunately do not have time to be your daily minion.

This is the first time I've witnessed anyone involved with PHP development
act in such a manner.  I hope it's not a sign of things to come.


Previous Comments:
---

[2001-06-19 16:45:30] [EMAIL PROTECTED]
Do you remember this:
 I have not tried the latest snapshots.  I tend to wait for point releases
to re
 test.
 Unfortunately I do not have that much time to keep retesting with the
nightly b
 uilds, etc.
 When 4.0.6 is released, I will test with that.

Then reopen this report when it is not fixed in 4.0.6.

period

---

[2001-06-19 10:56:24] [EMAIL PROTECTED]
What is this, the Microsoft approach to dealing with bugs?  You have no
evidence if the problem is resolved, yet you close out the problem anyway.
Burying your head in the sand doesn't make the issue go away.

I'm sorry, but you don't close a problem until a resolution is found and the
fix confirmed.  There is a session bug, which existed in early 4.0 releases,
was then fixed, and is now broken again.  The last working version of PHP
for Windows that did sessions properly was 4.0.3pl1, and nothing thus far
indicates that this issue has been resolved since then.

I have updated the PHP Version for you to reflect the problem still exists
in 4.0.5, the latest release most users would touch.  Most PHP users are not
about to touch nightly CVS builds.  That's why you HAVE point releases like
4.0.3pl1, 4.0.4, 4.0.5, etc.

This problem should remain open until it can be confirmed that the bug is
fixed.


---

[2001-06-19 09:27:34] [EMAIL PROTECTED]
Reopen this if it doesn't work with 4.0.6.

--Jani


---

[2001-06-15 11:08:43] [EMAIL PROTECTED]
I have not tried the latest snapshots.  I tend to wait for point releases to
retest.  Unfortunately I do not have that much time to keep retesting with
the nightly builds, etc.  When 4.0.6 is released, I will test with that.


---

[2001-06-14 23:18:19] [EMAIL PROTECTED]
Does this happen with latest snapshot from
http://www.zend.com/snapshots/ ??

There have been some fixes regarding this.

--Jani


---

The remainder of the comments for this report are too long.  To view the
rest of the comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=8989


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] Bug #8989 Updated: Bug#5493 resurfaced

2001-06-20 Thread derick

Hello,

On Wed, 20 Jun 2001, Brian Tanner wrote:

 They *think* that they fixed the bigger problem.  However, the best way to
 be *sure* (like you want) -- is to have people see if the symptoms are gone.
 Instead of recreating every problem that people describe... they try to fix
 the root cause, and see if all of the related problems go away.

Thank Brian you for clarifying this. I'm mostly doing too much at the same
time to explain things like this, (and I guess that's also the case for Jani),
so we just write small (and sometimes not-that-tact fullnotes). However,
getting mad does not work either, and will mostly make things only worse.
(i.e., makes us less eager to respond).

About the 4.0.6 RC's. These are mostly more stable than the previous
release (here 4.0.5). They are indeed not for production, but for
development servers and workstations they work very nice. And yes, I do
understand that not everybody can and will test nightly CVS builds, but IF
they are tested, than bugs are more quicker verified, found and fixed.
That is why we ask users to test RC's and nightly builds.

regards,

Derick


 Make sense?

 -Brian




 Amazing.  No report has been made that the bug has been resolved, yet you
 have a burr up your butt to close out the problem anyway.  Great debugging
 technique.  Truly professional.  Good to know PHP is in such good hands.

 Yes, to answer your comment, I DO remember that I wrote that.  In fact, it's
 basically a repeat of the same thing I wrote earlier, since you did not seem
 to pay attention the first time.  Each time a point release is out, I check
 it, as I--like many PHP users--would like to have the latest features and
 bug fixes.  PHP totally kicks ass, but unfortunately there are some glitches
 from time to time.

 HOWEVER, a nightly CVS build is not considered by most to be a stable
 release.  Ergo we have such things as RELEASE CANDIDATES.  PHP is now at
 4.0.6 RC3 if memory recalls correctly.  However, this too is not a full
 release.  RCs are basically like beta releases for those so inclined (and
 with sufficient time) to be guinea pigs.  CVS nightly builds are for those
 normally heavily involved, RCs are for those who want to help point out
 flaws in the next release, and then actual point releases are what most
 users obtain.

 I apologize if I don't satisfy your sudden demand for people to jump at
 testing your nightly builds or RCs.  But like many I actually have a job and
 life that requires most of my time.  I gladly test full point releases, but
 unfortunately do not have time to be your daily minion.

 This is the first time I've witnessed anyone involved with PHP development
 act in such a manner.  I hope it's not a sign of things to come.


 Previous Comments:
 ---

 [2001-06-19 16:45:30] [EMAIL PROTECTED]
 Do you remember this:
  I have not tried the latest snapshots.  I tend to wait for point releases
 to re
  test.
  Unfortunately I do not have that much time to keep retesting with the
 nightly b
  uilds, etc.
  When 4.0.6 is released, I will test with that.

 Then reopen this report when it is not fixed in 4.0.6.

 period

 ---

 [2001-06-19 10:56:24] [EMAIL PROTECTED]
 What is this, the Microsoft approach to dealing with bugs?  You have no
 evidence if the problem is resolved, yet you close out the problem anyway.
 Burying your head in the sand doesn't make the issue go away.

 I'm sorry, but you don't close a problem until a resolution is found and the
 fix confirmed.  There is a session bug, which existed in early 4.0 releases,
 was then fixed, and is now broken again.  The last working version of PHP
 for Windows that did sessions properly was 4.0.3pl1, and nothing thus far
 indicates that this issue has been resolved since then.

 I have updated the PHP Version for you to reflect the problem still exists
 in 4.0.5, the latest release most users would touch.  Most PHP users are not
 about to touch nightly CVS builds.  That's why you HAVE point releases like
 4.0.3pl1, 4.0.4, 4.0.5, etc.

 This problem should remain open until it can be confirmed that the bug is
 fixed.


 ---

 [2001-06-19 09:27:34] [EMAIL PROTECTED]
 Reopen this if it doesn't work with 4.0.6.

 --Jani


 ---

 [2001-06-15 11:08:43] [EMAIL PROTECTED]
 I have not tried the latest snapshots.  I tend to wait for point releases to
 retest.  Unfortunately I do not have that much time to keep retesting with
 the nightly builds, etc.  When 4.0.6 is released, I will test with that.


 ---

 [2001-06-14 23:18:19] [EMAIL PROTECTED]
 Does this happen with latest snapshot from
 http://www.zend.com/snapshots/ ??

 There have been some 

Re: [PHP-DEV] PHP 4.0.6 branch, bug #4630

2001-05-18 Thread Sascha Schumann

Hi,

I've committed a change which adds the -Wl,-bI:path bit to
LDFLAGS on AIX when building PHP as an Apache DSO.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] PHP 4.0.6 branch, bug #4630

2001-05-18 Thread Andi Gutmans

David,

Can you please grab the latest CVS and check if it fixes your problems. If 
it does I think it can be merged into 4.0.6.

Andi

At 10:58 PM 5/18/2001 +0200, Sascha Schumann wrote:
 Hi,

 I've committed a change which adds the -Wl,-bI:path bit to
 LDFLAGS on AIX when building PHP as an Apache DSO.

 - Sascha Experience IRCG
   http://schumann.cx/http://schumann.cx/ircg


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] PHP 4.0.6 branch, bug #4630

2001-05-18 Thread James Moore


 David,
 
 Can you please grab the latest CVS and check if it fixes your 
 problems. If 
 it does I think it can be merged into 4.0.6.

David,

Generally wed be appreciative if someone with AIX would think about
joining the PHP QA Team to ensure future versions of PHP also run on the
platform before they are released. Just testing a couple of RC's would
be great as we don't have any testers at present. Perhaps you could ask
some of the people who helped you with this report or provide an account
somewhere for one of the QA Team members to build and run tests on an
AIX machine. 

Cheers,

- James


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Bug #10829: call_user_func() - Bug

2001-05-12 Thread Thies C. Arntzen

On Sat, May 12, 2001 at 02:23:44PM -, [EMAIL PROTECTED] wrote:
 From: [EMAIL PROTECTED]
 Operating system: Win2K, Solaris
 PHP version:  4.0.5
 PHP Bug Type: Scripting Engine problem
 Bug description:  call_user_func() - Bug
 
 Hi,
 
 I have found the following bug with the function call_user_func():
 
 If the user function you are trying to call with 'call_user_func' requires any of 
its parameters to be passed by reference, PHP issues a warning stating that the 
function doesn't exist.
 
 Example:
 
 ?php
 function testme($param) {
  var_dump($param);
 }
 
 $func = testme;
 $param = array(1, 2);
 
 call_user_func($func, $param);
 
 ?
 
 Result:
 
 br
 bWarning/b:  Unable to call testme() - function does not exist in bt.php/b 
on line b1/bbr

if you take out the  in the testme argument list it works -
even weirder.

tc

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Bug #10829: call_user_func() - Bug

2001-05-12 Thread Sterling Hughes

Thies C. Arntzen wrote:

 On Sat, May 12, 2001 at 02:23:44PM -, [EMAIL PROTECTED] wrote:
 
From: [EMAIL PROTECTED]
Operating system: Win2K, Solaris
PHP version:  4.0.5
PHP Bug Type: Scripting Engine problem
Bug description:  call_user_func() - Bug

Hi,

I have found the following bug with the function call_user_func():

If the user function you are trying to call with 'call_user_func' requires any of 
its parameters to be passed by reference, PHP issues a warning stating that the 
function doesn't exist.

Example:

?php
function testme($param) {
 var_dump($param);
}

$func = testme;
$param = array(1, 2);

call_user_func($func, $param);

?

Result:

br
bWarning/b:  Unable to call testme() - function does not exist in bt.php/b 
on line b1/bbr

 
 if you take out the  in the testme argument list it works -
 even weirder.
 


Actually, it doesn't seem that wierd to me ;)

the call_user_func() expects an array of parameters, therefore, the 
correct code would look like:

$func = testme;
$param = array(1, 2);

call_user_func($func, array($param));

But instead the code passes a constant value 1 to the first argument, 
and 1 cannot be passed by reference.  The error generated is kinda a 
bug, call_user_func() should emit a more general error message, but 
otherwise its not a real bug.

-Sterling






-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Bug #10829: call_user_func() - Bug

2001-05-12 Thread Sterling Hughes

Sterling Hughes wrote:

 Thies C. Arntzen wrote:
 
 On Sat, May 12, 2001 at 02:23:44PM -, [EMAIL PROTECTED] wrote:

 From: [EMAIL PROTECTED]
 Operating system: Win2K, Solaris
 PHP version:  4.0.5
 PHP Bug Type: Scripting Engine problem
 Bug description:  call_user_func() - Bug

 Hi,

 I have found the following bug with the function call_user_func():

 If the user function you are trying to call with 'call_user_func' 
 requires any of its parameters to be passed by reference, PHP issues 
 a warning stating that the function doesn't exist.

 Example:

 ?php
 function testme($param) {
 var_dump($param);
 }

 $func = testme;
 $param = array(1, 2);

 call_user_func($func, $param);

 ?

 Result:

 br
 bWarning/b:  Unable to call testme() - function does not exist in 
 bt.php/b on line b1/bbr


 if you take out the  in the testme argument list it works -
 even weirder.

 
 
 Actually, it doesn't seem that wierd to me ;)
 
 the call_user_func() expects an array of parameters, therefore, the 
 correct code would look like:
 
 $func = testme;
 $param = array(1, 2);
 
 call_user_func($func, array($param));
 
 But instead the code passes a constant value 1 to the first argument, 
 and 1 cannot be passed by reference.  The error generated is kinda a 
 bug, call_user_func() should emit a more general error message, but 
 otherwise its not a real bug.


Never mind, I take this back ;)))

call_user_func  call_user_func_array() got confused in head.

Take a look at the call_user_*() thread ;)

-Sterling

 




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Alexander Bokovoy wrote:

 This code branch should only be triggered if HAVE_IMAP_SSL is defined, which
 should only happen if you configure php --with-imap-ssl. If you're doing so,
 it's assumed that you've built c-client with SSL support.

Current configure macros in PHP 4.0.x have flaw that breaks your
assumption. ext/imap uses several PHP_ARG_WITH() macros in order to find
out configuration options. When building ext/imap as standalone
dynamically loadable module via phpize (self-contained extension),
PHP_ARG_WITH() relies on the value of $php_always_shared (which is 'yes'
here) so result of PHP_ARG_WITH always be 'yes' regardless of user input
or system checks.

You're both wrong. This is really a bug in the IMAP-2001.beta sources.
It's not possible to build it with SSL support on Unix.

This is known bug since early March but nobody fixed it and in general
fixing requires serious rework of PHP4's configure macros concept.

Submit a patch or shut up.

--Jani


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread J. Jones

On Thu, May 03, 2001 at 09:28:03AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
  This code branch should only be triggered if HAVE_IMAP_SSL is defined, which
  should only happen if you configure php --with-imap-ssl. If you're doing so,
  it's assumed that you've built c-client with SSL support.
 
 Current configure macros in PHP 4.0.x have flaw that breaks your
 assumption. ext/imap uses several PHP_ARG_WITH() macros in order to find
 out configuration options. When building ext/imap as standalone
 dynamically loadable module via phpize (self-contained extension),
 PHP_ARG_WITH() relies on the value of $php_always_shared (which is 'yes'
 here) so result of PHP_ARG_WITH always be 'yes' regardless of user input
 or system checks.
 
 You're both wrong. This is really a bug in the IMAP-2001.beta sources.
 It's not possible to build it with SSL support on Unix.
 
 This is known bug since early March but nobody fixed it and in general
 fixing requires serious rework of PHP4's configure macros concept.
 
 Submit a patch or shut up.
 
 --Jani
 

Guys (and gals), my original message was simply stating the symptoms of
the 'bug' reported, then the actual solution for it.

It IS imap 2000*, not php.  It does not build itself with ssl unless
specifically told to.

The Makefile for imap explains.

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 09:28:03AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
  This code branch should only be triggered if HAVE_IMAP_SSL is defined, which
  should only happen if you configure php --with-imap-ssl. If you're doing so,
  it's assumed that you've built c-client with SSL support.
 
 Current configure macros in PHP 4.0.x have flaw that breaks your
 assumption. ext/imap uses several PHP_ARG_WITH() macros in order to find
 out configuration options. When building ext/imap as standalone
 dynamically loadable module via phpize (self-contained extension),
 PHP_ARG_WITH() relies on the value of $php_always_shared (which is 'yes'
 here) so result of PHP_ARG_WITH always be 'yes' regardless of user input
 or system checks.
 
 You're both wrong. This is really a bug in the IMAP-2001.beta sources.
 It's not possible to build it with SSL support on Unix.
It is possible and I did it, and it works. That's why I'm saying about it.
Look closer to the circumstances where this bug in configure rises.
It occurs when compiling extension via phpize, not with whole PHP4 tree.


 This is known bug since early March but nobody fixed it and in general
 fixing requires serious rework of PHP4's configure macros concept.
 
 Submit a patch or shut up.
Very nice answer. So, keep broken functionality forever.


-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Alexander Bokovoy wrote:

 You're both wrong. This is really a bug in the IMAP-2001.beta sources.
 It's not possible to build it with SSL support on Unix.

It is possible and I did it, and it works. That's why I'm saying about it.
Look closer to the circumstances where this bug in configure rises.
It occurs when compiling extension via phpize, not with whole PHP4 tree.

I got the latest IMAP-2001.beta snapshot and it doesn't work.
There isn't any auth_ssl.c file in the package. So please explain
me how it can be done? Anyway, like I said, IMAP-2000 works fine.

IMAP-2001.beta doesn't work but it doesn't even matter as it still is _beta_.

 This is known bug since early March but nobody fixed it and in general
 fixing requires serious rework of PHP4's configure macros concept.

 Submit a patch or shut up.
Very nice answer. So, keep broken functionality forever.

Hrhm. If you know what is wrong then fix it and send a patch.
Or at least point us WHERE the problem is. Everything works
for me just fine as it is - no broken functionality.

Just saying requires serious rework of PHP4's configure macros concept
isn't really useful at all. There are enough people saying that
_something_ should be done but not enough who can say _what_ should be done.

--Jani


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 10:43:21AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
  You're both wrong. This is really a bug in the IMAP-2001.beta sources.
  It's not possible to build it with SSL support on Unix.
 
 It is possible and I did it, and it works. That's why I'm saying about it.
 Look closer to the circumstances where this bug in configure rises.
 It occurs when compiling extension via phpize, not with whole PHP4 tree.
 
 I got the latest IMAP-2001.beta snapshot and it doesn't work.
 There isn't any auth_ssl.c file in the package. So please explain
 me how it can be done? Anyway, like I said, IMAP-2000 works fine.
 
 IMAP-2001.beta doesn't work but it doesn't even matter as it still is _beta_.
As original author already pointed out, error triggers out with IMAP
2000*, not with IMAP 2001 betas. And I'm saying about it too. With
IMAP-2000 ext/imap does not compiles well using phpize because both
PHP_ARG_WITH() in its config.m4.

 
  This is known bug since early March but nobody fixed it and in general
  fixing requires serious rework of PHP4's configure macros concept.
 
  Submit a patch or shut up.
 Very nice answer. So, keep broken functionality forever.
 
 Hrhm. If you know what is wrong then fix it and send a patch.
 Or at least point us WHERE the problem is. Everything works
 for me just fine as it is - no broken functionality.
 
 Just saying requires serious rework of PHP4's configure macros concept
 isn't really useful at all. There are enough people saying that
 _something_ should be done but not enough who can say _what_ should be done.
I'm saying about it for two months now. Even posted two bug reports.
Nothing changes. OK, repeat again:

--- acinclude.m4 ---
AC_DEFUN(PHP_ARG_ANALYZE,[
case [$]$1 in
shared,*)
  ext_output=yes, shared
  ext_shared=yes
  $1=`echo [$]$1|sed 's/^shared,//'`
  ;;
shared)
  ext_output=yes, shared
  ext_shared=yes
  $1=yes
  ;;
no)
  ext_output=no
  ext_shared=no
  ;;
*)
  ext_output=yes
  ext_shared=no
  ;;
esac

if test $php_always_shared = yes; then
  ext_output=yes, shared
  ext_shared=yes
  test [$]$1 = no  $1=yes
fi

--

When using phpize for compiling self contained extensions,
$php_always_shared is set to 'yes' unconditionally by pear/pear.m4, 
so for any PHP_ARG_WITH(symbol, blah, blah, blah) call result will be 
ext_output='yes, shared'
ext_shared=yes
symbol=yes

This occurs regardless of any onfigure checks because of
  if test $php_always_shared = yes; then
ext_output=yes, shared
ext_shared=yes
test [$]$1 = no  $1=yes
  fi

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Sascha Schumann

 This is known bug since early March but nobody fixed it and in general
 fixing requires serious rework of PHP4's configure macros concept.

I plan to address this by introducing two new macros which
can embrace the sections which contain optional
PHP_ARG_WITH/PHP_ARG_ENABLE macros.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 10:43:21AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
  You're both wrong. This is really a bug in the IMAP-2001.beta sources.
  It's not possible to build it with SSL support on Unix.
 
 It is possible and I did it, and it works. That's why I'm saying about it.
 Look closer to the circumstances where this bug in configure rises.
 It occurs when compiling extension via phpize, not with whole PHP4 tree.
 
 I got the latest IMAP-2001.beta snapshot and it doesn't work.
 There isn't any auth_ssl.c file in the package. So please explain
 me how it can be done? Anyway, like I said, IMAP-2000 works fine.
 
 IMAP-2001.beta doesn't work but it doesn't even matter as it still is _beta_.
 
  This is known bug since early March but nobody fixed it and in general
  fixing requires serious rework of PHP4's configure macros concept.
 
  Submit a patch or shut up.
 Very nice answer. So, keep broken functionality forever.
 
 Hrhm. If you know what is wrong then fix it and send a patch.
 Or at least point us WHERE the problem is. Everything works
 for me just fine as it is - no broken functionality.
So, it means that you never test PHP extensions in SCE mode.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 10:54:19AM +0200, Sascha Schumann wrote:
  This is known bug since early March but nobody fixed it and in general
  fixing requires serious rework of PHP4's configure macros concept.
 
 I plan to address this by introducing two new macros which
 can embrace the sections which contain optional
 PHP_ARG_WITH/PHP_ARG_ENABLE macros.
Yes, it might be solution. If you need my help in testing, just ask for
it.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Alexander Bokovoy wrote:

 IMAP-2001.beta doesn't work but it doesn't even matter as it still is _beta_.
As original author already pointed out, error triggers out with IMAP
2000*, not with IMAP 2001 betas. And I'm saying about it too. With

Please read that bug report. It only talks about IMAP-2001.
And IMAP-2000 works fine. I just compiled it and PHP compiles with it just
fine.

IMAP-2000 ext/imap does not compiles well using phpize because both
PHP_ARG_WITH() in its config.m4.

Why would anyone want to use phpize on imap extension?
(forgive me but I never have needed phpize..)

Thanks for the patches. I hope someone more familiar
with this will check them out and commit them.

--Jani



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Alexander Bokovoy wrote:

 Hrhm. If you know what is wrong then fix it and send a patch.
 Or at least point us WHERE the problem is. Everything works
 for me just fine as it is - no broken functionality.
So, it means that you never test PHP extensions in SCE mode.

So? I have no use for SCEs.

--Jani



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Emiliano

Jani Taskinen wrote:


 IMAP-2000 ext/imap does not compiles well using phpize because both
 PHP_ARG_WITH() in its config.m4.
 
 Why would anyone want to use phpize on imap extension?
 (forgive me but I never have needed phpize..)

You do when you want to develop self-contained extensions. SCEs are 
useful for large PHP extensions that have to live outside the main PHP 
tree, or for package builders that want to develop a main php4 package 
and separate packages for the extensions (much like debian does).

Emile


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 11:19:10AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
  IMAP-2001.beta doesn't work but it doesn't even matter as it still is _beta_.
 As original author already pointed out, error triggers out with IMAP
 2000*, not with IMAP 2001 betas. And I'm saying about it too. With
 
 Please read that bug report. It only talks about IMAP-2001.
 And IMAP-2000 works fine. I just compiled it and PHP compiles with it just
 fine.
 
 IMAP-2000 ext/imap does not compiles well using phpize because both
 PHP_ARG_WITH() in its config.m4.
 
 Why would anyone want to use phpize on imap extension?
 (forgive me but I never have needed phpize..)
It is absolutly needed for distribution purposes. It is generally strange
to compile in, f.e. IMAP extension, into main PHP binary and make it
available in Linux distribution because it implies additional unneeded 
dependencies. That's why almost all extensions like IMAP, MySQL, PGSQL,
sockets, GD, PDF, etc could and should be compiled out of PHP4 source.
This also includes more manageable RPM or DEB specs. Imagine build of
15-20 packages from one source RPM. For example, in our ALT Linux
distribution we are packaging 18 PHP4 extensions including PHP-GTK which
specifically designed to be build as SCE.

 
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Emiliano

Jani Taskinen wrote:


 So, it means that you never test PHP extensions in SCE mode.
 
 So? I have no use for SCEs.

All the world, fall in line with Jani. Some people do need them.
For PHP too, see package argument earlier.

Emile


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 11:21:28AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
  Hrhm. If you know what is wrong then fix it and send a patch.
  Or at least point us WHERE the problem is. Everything works
  for me just fine as it is - no broken functionality.
 So, it means that you never test PHP extensions in SCE mode.
 
 So? I have no use for SCEs.
Then you can't talk about 'no broken functionality' or trust those who
checks this mode and reports about problems.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Emiliano wrote:

Jani Taskinen wrote:
 Why would anyone want to use phpize on imap extension?
 (forgive me but I never have needed phpize..)

You do when you want to develop self-contained extensions. SCEs are
useful for large PHP extensions that have to live outside the main PHP
tree, or for package builders that want to develop a main php4 package
and separate packages for the extensions (much like debian does).

Well, this is off topic. I was talking about the IMAP extension
that lives in inside the main PHP tree and it doesn't have any
use for phpize.

--Jani



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Alexander Bokovoy wrote:

On Thu, May 03, 2001 at 11:21:28AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:

  Hrhm. If you know what is wrong then fix it and send a patch.
  Or at least point us WHERE the problem is. Everything works
  for me just fine as it is - no broken functionality.
 So, it means that you never test PHP extensions in SCE mode.

 So? I have no use for SCEs.
Then you can't talk about 'no broken functionality' or trust those who
checks this mode and reports about problems.

True and that's why I said that someone else should look at those
patches you send. I'll shut up now about this. For most of the
PHP users the IMAP extension (among all the other) work just fine
and they don't need to compile them as SCEs. And that's enough for me.

I just wonder why you had to start arguing about this as the
original bug report doesn't say ANYTHING about compiling any extensions
as SCEs..

--Jani


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Emiliano

Jani Taskinen wrote:


 You do when you want to develop self-contained extensions. SCEs are
 useful for large PHP extensions that have to live outside the main PHP
 tree, or for package builders that want to develop a main php4 package
 and separate packages for the extensions (much like debian does).
 
 Well, this is off topic.

It isn't, IMO.

 I was talking about the IMAP extension
 that lives in inside the main PHP tree and it doesn't have any
 use for phpize.

Even inside the main PHP tree you can use phpize to generate separately 
loadable modules for segmented packaging. The only other way to do 
binary packaging is to make assumptions on behalf of the downloaders as 
to what extensions are useful to them. Not very friendly.

Since you're the IMAP extension maintainer (or so I gather), ignoring 
that valid use is your option, of course. No obligation to anyone. But 
there is a valid use, and one that's in frequent use too. Debian has 
about 20 of the extensions that are available in the main tree as SCEs. 
And yes, including IMAP.

Emile


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Jani Taskinen


Can we drop this issue already? Sascha said his working on it, okay?
FYI: I'm not the maintainer of IMAP extension. Check EXTENSIONS file.

--Jani


On Thu, 3 May 2001, Emiliano wrote:

Jani Taskinen wrote:


 You do when you want to develop self-contained extensions. SCEs are
 useful for large PHP extensions that have to live outside the main PHP
 tree, or for package builders that want to develop a main php4 package
 and separate packages for the extensions (much like debian does).

 Well, this is off topic.

It isn't, IMO.

 I was talking about the IMAP extension
 that lives in inside the main PHP tree and it doesn't have any
 use for phpize.

Even inside the main PHP tree you can use phpize to generate separately
loadable modules for segmented packaging. The only other way to do
binary packaging is to make assumptions on behalf of the downloaders as
to what extensions are useful to them. Not very friendly.

Since you're the IMAP extension maintainer (or so I gather), ignoring
that valid use is your option, of course. No obligation to anyone. But
there is a valid use, and one that's in frequent use too. Debian has
about 20 of the extensions that are available in the main tree as SCEs.
And yes, including IMAP.

Emile





-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 11:57:14AM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Emiliano wrote:
 
 Jani Taskinen wrote:
  Why would anyone want to use phpize on imap extension?
  (forgive me but I never have needed phpize..)
 
 You do when you want to develop self-contained extensions. SCEs are
 useful for large PHP extensions that have to live outside the main PHP
 tree, or for package builders that want to develop a main php4 package
 and separate packages for the extensions (much like debian does).
 
 Well, this is off topic. I was talking about the IMAP extension
 that lives in inside the main PHP tree and it doesn't have any
 use for phpize.
Any extension can be built using phpize, there is no serious difference in
building process with or without it except for discussed one. It is needed
for distribution vendors. No matter where extension lives, it needs to be
packaged and build separately of building PHP binary itself (or different
SAPI module). This is just for better management of building process. Of
course, this is up to distribution vendors how to make this process, but
why to complicate work? Many people use vendor-provided binaries for
PHP and it's modules.

In addition, environment to build extensions as SCE was one of the most
valuable achievements of PHP4, isn't it? :-)

Enough on this topic, let's back to work :-)

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-03 Thread Alexander Bokovoy

On Thu, May 03, 2001 at 12:07:47PM +0200, Jani Taskinen wrote:
 On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
 On Thu, May 03, 2001 at 11:21:28AM +0200, Jani Taskinen wrote:
  On Thu, 3 May 2001, Alexander Bokovoy wrote:
 
   Hrhm. If you know what is wrong then fix it and send a patch.
   Or at least point us WHERE the problem is. Everything works
   for me just fine as it is - no broken functionality.
  So, it means that you never test PHP extensions in SCE mode.
 
  So? I have no use for SCEs.
 Then you can't talk about 'no broken functionality' or trust those who
 checks this mode and reports about problems.
 
 True and that's why I said that someone else should look at those
 patches you send. I'll shut up now about this. For most of the
 PHP users the IMAP extension (among all the other) work just fine
 and they don't need to compile them as SCEs. And that's enough for me.
 
 I just wonder why you had to start arguing about this as the
 original bug report doesn't say ANYTHING about compiling any extensions
 as SCEs..
My fault here to adding existing problem with IMAP extension to different
one with this extension too. IMAP extension is one of those with 
'broken' config.m4 which work with usual configure process and fail with
phpize. 
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-02 Thread Chuck Hagenbuch

Quoting J. Jones [EMAIL PROTECTED]:

 The imap module fails with the following (perhaps only when building
 against imap-2000*):
 
 php_imap.c: In function `php_minit_imap':
 php_imap.c:450: `auth_ssl' undeclared (first use in this function)
 php_imap.c:450: (Each undeclared identifier is reported only once
 php_imap.c:450: for each function it appears in.)

This code branch should only be triggered if HAVE_IMAP_SSL is defined, which 
should only happen if you configure php --with-imap-ssl. If you're doing so, 
it's assumed that you've built c-client with SSL support.

-chuck

--
Charles Hagenbuch, [EMAIL PROTECTED]
You will receive an urgent transmission from the Martian government informing 
you that Mars does not, in fact, need women, so please stop sending them.

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-05-02 Thread Alexander Bokovoy

On Wed, May 02, 2001 at 01:50:08PM -0400, Chuck Hagenbuch wrote:
 Quoting J. Jones [EMAIL PROTECTED]:
 
  The imap module fails with the following (perhaps only when building
  against imap-2000*):
  
  php_imap.c: In function `php_minit_imap':
  php_imap.c:450: `auth_ssl' undeclared (first use in this function)
  php_imap.c:450: (Each undeclared identifier is reported only once
  php_imap.c:450: for each function it appears in.)
 
 This code branch should only be triggered if HAVE_IMAP_SSL is defined, which 
 should only happen if you configure php --with-imap-ssl. If you're doing so, 
 it's assumed that you've built c-client with SSL support.
Current configure macros in PHP 4.0.x have flaw that breaks your
assumption. ext/imap uses several PHP_ARG_WITH() macros in order to find
out configuration options. When building ext/imap as standalone
dynamically loadable module via phpize (self-contained extension),
PHP_ARG_WITH() relies on the value of $php_always_shared (which is 'yes'
here) so result of PHP_ARG_WITH always be 'yes' regardless of user input
or system checks.

This is known bug since early March but nobody fixed it and in general
fixing requires serious rework of PHP4's configure macros concept.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Imap SSL support (Bug #10330)

2001-04-30 Thread J. Jones

On Mon, Apr 30, 2001 at 01:22:32PM -0500, J. Jones wrote:
 
 make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=/path/to/openssl/includes/
 

Whoops! make that

make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=-I/path/to/openssl/includes/

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] RE: PHP 4.0 Bug #10299 Updated: CPU and Memory Spike

2001-04-15 Thread Derick Rethans

On Sun, 15 Apr 2001, Derek Leung wrote:

 I did try the snap shot 4/14/2001 4.06dev, it didnt' solve the problem.

 If 256mb ram , dual 400mhz can only serve around 10 concurrent clients, this
 is a MAJOR issue for PHP.  I guess any web language like PERL, Cold fusion,
 JSP, servlet can do a LOT more than this with the equipment I am using right
 now.

Well, my Pentium 133 with 48MB's of RAM even gets around 25 concurrent
connections...


Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] RE: PHP 4.0 Bug #10299 Updated: CPU and Memory Spike

2001-04-15 Thread Goten

That's my whole point.  PHP should be able handle it pretty well.  But 
Chris Adams said my setup can only support 10 concurrent 
connections.  That's why I am curious what is wrong here.

I am pretty sure PHP can handle the load, but somehow something trigger the 
CPU spike.  I just can't find out why.

rgd,
Derek


-Original Message-
From: Derick Rethans
To: Derek Leung
Cc: '[EMAIL PROTECTED]'
Sent: 4/15/01 9:34 AM
Subject: Re: [PHP-DEV] RE: PHP 4.0 Bug #10299 Updated: CPU and Memory Spike

On Sun, 15 Apr 2001, Derek Leung wrote:

  I did try the snap shot 4/14/2001 4.06dev, it didnt' solve the
problem.
 
  If 256mb ram , dual 400mhz can only serve around 10 concurrent
clients, this
  is a MAJOR issue for PHP.  I guess any web language like PERL, Cold
fusion,
  JSP, servlet can do a LOT more than this with the equipment I am using
right
  now.

Well, my Pentium 133 with 48MB's of RAM even gets around 25 concurrent
connections...


Derick Rethans


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #9964 Updated: Unresolved symbols

2001-04-04 Thread Daniel Beulshausen

At 16:34 03.04.2001 -0700, Joe Brown wrote:
Have you looked at the instructions at
http://www.php4win.de
under articles/compiling -english version?

yeah, because i've writtem them :)
i'm not talking about the php4ts.dll, i'm taking about extensions using the 
COM interface (it seems to be broken...)
i.e. the .NET extension fails to link.

daniel

--- Bug Database [EMAIL PROTECTED] wrote:
  ID: 9964
  Updated by: dbeu
  Reported By: [EMAIL PROTECTED]
  Old-Status: Open
  Status: Analyzed
  Bug Type: Compile Failure
  Assigned To:
  Comments:
 
  com linkage still seems to be broken (external
  modules like dotnet fail to link).
  can someone familiar with them please have a look at
  it?
 
  Previous Comments:
 
---
 
  [2001-03-26 01:47:39] [EMAIL PROTECTED]
  I was trying to build with php.dsw workspace.
  phpts.dsw compiles right up.  Must have neglected to
  read the instructions.  Leaving this ticket open,
  because I think php4.dsw should be removed from the
  distribution, unless it serves some other purpose.
 
 
---
 
  [2001-03-24 01:12:25] [EMAIL PROTECTED]
  Trying to build php from recent cvs snaps
  php4-200103231245 and one from a day earlier.
 
  Compile is smooth, except for a few unresolved
  symbols:
 
  Linking...
 Creating library ..Debug/php4nts_debug.lib and
  object ..Debug/php4nts_debug.exp
  internal_functions_win32.obj : error LNK2001:
  unresolved external symbol _VARIANT_module_entry
  COM.obj : error LNK2001: unresolved external symbol
  _php_char_to_OLECHAR
  COM.obj : error LNK2001: unresolved external symbol
  _php_OLECHAR_to_char
  COM.obj : error LNK2001: unresolved external symbol
  _php_pval_to_variant
  COM.obj : error LNK2001: unresolved external symbol
  _php_variant_to_pval
  ..Debugphp4nts_debug.dll : fatal error LNK1120: 5
  unresolved externals
  Error executing link.exe.
 
  php4nts_debug.dll - 6 error(s), 0 warning(s)
 
 
---
 
 
 
  ATTENTION! Do NOT reply to this email!
  To reply, use the web interface found at
  http://bugs.php.net/?id=9964edit=2
 


__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.de


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #9489 Updated: The mail() function doesn't return the success or error

2001-04-03 Thread Hartmut Holzgraefe

Star-Tools Team wrote:
 I've outputed the return value by using the following code:
 $Result = mail(...)
 echo "-$Result-";
 
 The output was "--"!

so $Result was either empty or 'false'
as false converts to an empty string 

you might try this instead:

  echo ($Result===false)?"-false-":"-$Result-";

instead

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #10051 Updated: php still does not start

2001-03-29 Thread Hartmut Holzgraefe

wolle wrote:
 
 you say, misconfig of MY system ! how have I to configure it? what do I have
 to install, in order to get rid of that error-message?
 
 I cant image to be the first person, that has this problem... I have a new
 typical installation of win98...
 
 Please help me, I didnt want to bug you.
 

as you can see by its name, odbc32.dll is not a php library
it is most likely (c) Microsoft so it wouldn't even be legaly
possible to include it in php binary distribution

but you shouldn't expect php to include each and every library
it may support by its extensions anyway, thats why they are called
extensions

in this special case i'd guess you have to have some product that
provides ODBC services installed, for example MS Access, MS SQL Server
Client or any other Database Server or Client for MS Windows

so don't blame *us* for missing pieces on *your* system

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77 

Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] RE: PHP 4.0 Bug #10024 Updated:

2001-03-27 Thread Jani Taskinen


You submitted the report twice, this one was totally empty.
The other bug report, #10025 is allright.

--Jani


On Tue, 27 Mar 2001, Hugh Jones wrote:

I read that before submitting the bug, and nowhere on the site can I find
anything about this problem!

-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: 27 March 2001 16:53
To: [EMAIL PROTECTED]
Subject: PHP 4.0 Bug #10024 Updated:


ID: 10024
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Compile Failure
Assigned To:
Comments:

http://www.php.net/bugs-dos-and-donts.php


Previous Comments:
---

[2001-03-27 10:49:49] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=10024edit=2



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #9931 Updated: under Communicator 4.76 {basename(PHP_SELF) doesn't return value}

2001-03-23 Thread Hartmut Holzgraefe

Ieleja wrote:
 
 my situation:
 
 is
 common.function.php
 function_abc()
 {
 $return_string = basename($PHP_SELF);
 return $return_string;
 }
 
 un ir
 
 listing.php
 {
 include("common.functions.inc.php");
 
 ? echo function_abc(); ?
 }
 
 and there function () returns empty string ...
 

add "global $PHP_SELF;" in function_abc and it will work

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77 

Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #9849 Updated: Square boxes?

2001-03-19 Thread eschmid+sic

On Mon, Mar 19, 2001 at 05:01:00PM -0600, Jason Gulledge wrote:

  This webpage is what I'm using to install php4 / Apache 1.3.19
  http://www.php.net/manual/kr/install.apache.php
  and there squares everywhere on the page from what I can see

I have seen such square rectangles with M$ IE in the Japanese PHP manual.
With Netscape it looks fine, but I don't understand it anyway. So use
other browsers or play with the language settings for your favorite
browser.

-Egon

 __ Reply Separator _
 Subject: PHP 4.0 Bug #9849 Updated: Square boxes?
 Author:  [EMAIL PROTECTED] (Bug Database) at INTERNET
 Date:3/19/01 4:44 PM
 
 
 ID: 9849
 Updated by: torben
 Reported By: [EMAIL PROTECTED] 
 Old-Status: Open
 Status: Feedback
 Bug Type: Documentation problem
 Assigned To:
 Comments:
  
 Um...which square boxes, exactly? :) The user notes, the 
 warnings, the tables, what? It sort of sounds like making the 
 boxes less square would solve your problem, but I honestly 
 doubt that it's square boxes which are causing your problem.
  
 Which information did you find useless and/or misleading? If 
 you can give us a better handle on the problems you're having 
 it'll be easier to fix.
  
 Thanks,
  
 Torben
  
 Previous Comments:
 ---
  
 [2001-03-19 17:25:23] [EMAIL PROTECTED]
 Is there a reason there are so many square blocks of useless data on this websit
 e
  
  
 I'm trying to install PHP/Apache and get a Core dump everytime I try to start Ap
 ache. I think it may be due to  a step that's not clearly documented on the PHP 
 website because of these square boxes replacing actual, useful data [which I can
 not see].
  
 ---
  
  
  
 ATTENTION! Do NOT reply to this email!
 To reply, use the web interface found at http://bugs.php.net/?id=9849edit=2
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]
 

-- 
-- 
LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
All known books about PHP and related books: http://php.net/books.php 
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] Re: PHP 4.0 Bug #9849 Updated: Square boxes?

2001-03-19 Thread Chris Newbill

Those square boxes are shown when IE cannot find the character in the
particular font/language set.  If you enable "Install on demand" it will
usually prompt you to download the language pack for whatever language you
are trying to view.

-Chris

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: Monday, 19 March, 2001 4-27 pM
 To: Jason Gulledge; Bug Database
 Subject: Re: [PHP-DEV] Re: PHP 4.0 Bug #9849 Updated: Square boxes?


 On Mon, Mar 19, 2001 at 05:01:00PM -0600, Jason Gulledge wrote:

   This webpage is what I'm using to install php4 / Apache 1.3.19
   http://www.php.net/manual/kr/install.apache.php
   and there squares everywhere on the page from what I can see

 I have seen such square rectangles with M$ IE in the Japanese PHP manual.
 With Netscape it looks fine, but I don't understand it anyway. So use
 other browsers or play with the language settings for your favorite
 browser.

 -Egon

  __ Reply Separator
 _
  Subject: PHP 4.0 Bug #9849 Updated: Square boxes?
  Author:  [EMAIL PROTECTED] (Bug Database) at INTERNET
  Date:3/19/01 4:44 PM
 
 
  ID: 9849
  Updated by: torben
  Reported By: [EMAIL PROTECTED]
  Old-Status: Open
  Status: Feedback
  Bug Type: Documentation problem
  Assigned To:
  Comments:
 
  Um...which square boxes, exactly? :) The user notes, the
  warnings, the tables, what? It sort of sounds like making the
  boxes less square would solve your problem, but I honestly
  doubt that it's square boxes which are causing your problem.
 
  Which information did you find useless and/or misleading? If
  you can give us a better handle on the problems you're having
  it'll be easier to fix.
 
  Thanks,
 
  Torben
 
  Previous Comments:
 
 --
 -
 
  [2001-03-19 17:25:23] [EMAIL PROTECTED]
  Is there a reason there are so many square blocks of useless
 data on this websit
  e
 
 
  I'm trying to install PHP/Apache and get a Core dump everytime
 I try to start Ap
  ache. I think it may be due to  a step that's not clearly
 documented on the PHP
  website because of these square boxes replacing actual, useful
 data [which I can
  not see].
 
 
 --
 -
 
 
 
  ATTENTION! Do NOT reply to this email!
  To reply, use the web interface found at
 http://bugs.php.net/?id=9849edit=2
 
  --
  PHP Development Mailing List http://www.php.net/
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  To contact the list administrators, e-mail: [EMAIL PROTECTED]
 

 --
 --
 LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
 All known books about PHP and related books: http://php.net/books.php
 Concert Band of the University of Hohenheim: http://www.concert-band.de/
 First and second bestselling book in German: http://www.php-buch.de/

 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] RE: PHP 4.0 Bug #9745 Updated: PHP Warning: Unable toload dynamic library './msql.dll'

2001-03-14 Thread Joey Smith

Open a new bug. You reported two bugs in the same place. You had the
msql.dll bug, and:

Parse error: parse error, expecting `','' or `';''

On Wed, 14 Mar 2001, John Stoops wrote the following to Bug Database :

 Lets start again.
 
 My php page:
 
 !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
 html
 head
   titleUntitled/title
 /head
 body
 ?php
   echo "Hello world";
 ?
 /body
 /html
 
 My error message:
 
 PHP Warning: Unable to load dynamic library './msql.dll' - One of the
 library files needed to run this application cannot be found. in Unknown on
 line 0
 
 
 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] RE: PHP 4.0 Bug #9745 Updated: PHP Warning: Unable toload dynamic library './msql.dll'

2001-03-14 Thread Jani Taskinen

On Wed, 14 Mar 2001, John Stoops wrote:

Lets start again.

My php page:

!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
html
head
   titleUntitled/title
/head
body
?php
   echo "Hello world";
?
/body
/html

My error message:

PHP Warning: Unable to load dynamic library './msql.dll' - One of the
library files needed to run this application cannot be found. in Unknown on
line 0


msql.dll ?? Weren't you using mysql? It's mysql.dll then.

--Jani



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] RE: PHP 4.0 Bug #9745 Updated: PHP Warning: Unable toload dynamic library './msql.dll'

2001-03-14 Thread Joey Smith

Actually, he doesn't need either.

Just put a semi-colon in front of the line starting:
extension=msql.dll

Note the section a few lines down:
;Note that MySQL and ODBC support is now built in, so no dll is needed
for it.


On Wed, 14 Mar 2001, Jani Taskinen wrote the following to John Stoops :

 On Wed, 14 Mar 2001, John Stoops wrote:
 
 Lets start again.
 
 My php page:
 
 !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
 html
 head
  titleUntitled/title
 /head
 body
 ?php
  echo "Hello world";
 ?
 /body
 /html
 
 My error message:
 
 PHP Warning: Unable to load dynamic library './msql.dll' - One of the
 library files needed to run this application cannot be found. in Unknown on
 line 0
 
 
 msql.dll ?? Weren't you using mysql? It's mysql.dll then.
 
 --Jani
 
 
 
 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] RE: PHP 4.0 Bug #9715 Updated: Memory leak when passingstring values to modular variables in COM

2001-03-13 Thread Jani Taskinen

On Wed, 14 Mar 2001, Jason Gan wrote:

Hi Sniper:

Actually I was posting two different cases of possibly the same bug.

One bug, one report. Add the other example into the other report you
posted.

--Jani


One case is passing String value to a static variable in the COM object.
The other is passing String value as an argument in a method exposed by the
COM object.
They both leak memory, and all my php-com work is leaking memory so this is
not an isolated problem.
I use VJ++ to write COM objects, as Java handles its own garbage collection.


-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, 14 March 2001 8:09 AM
To: [EMAIL PROTECTED]
Subject: PHP 4.0 Bug #9715 Updated: Memory leak when passing string
values to modular variables in COM


ID: 9715
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: COM related
Assigned To:
Comments:

submitted twice

Previous Comments:
---

[2001-03-12 22:17:54] [EMAIL PROTECTED]
That wasn't it... I tried it without passing a constant, and it's still
leaking memory! So this is an outstanding serious bug with no workaround.

---

[2001-03-12 22:02:03] [EMAIL PROTECTED]
Found the problem. It only leaks memory, if I pass a CONSTANT from PHP to
the COM object. All I have to do now is rewrite the php so that I'm passing
a variable, not a constant.  Probably this issue can be closed after someone
has a look into it.

---

[2001-03-12 19:56:02] [EMAIL PROTECTED]
This is a new bug that I found.  Memory is leaked when passing string values
to String variables in the modular scope of the COM object.  Example:  COM
object has public variable called temp which is of String data type.  I
instantiate the COM object and reference it with $t_obj. I pass a string
value from php like this:-  $t_obj-temp = "This is a test string.";  PHP
has many other bugs concerning passing values through COM, but this bug is
more serious because I am only trying to pass String values to the variables
directly, without having to call a method to pass the values to the
variables.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9715edit=2






-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #8657 Updated: Errormessage on theBrowser if using UNC path notation for document root

2001-03-12 Thread Stanislav Malyshev

PM i see the html output
PM if i call
PM php \\server\vol\dir\phptest.php
PM there is no output and no errormessage.
PM If i map \\server\vol to w: and call
PM php w:\dir\phptest.php
PM it works.

PHP is not too good with UNC pathnames (actually, it just cannot grok
them). Someone with Windows programming  background should look on this.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #9307 Updated: Numeric-looking arraykeys are forced to be integers

2001-03-06 Thread Stanislav Malyshev

DC Even for array keys that are *not numbers*? How do I get a
DC string for my array key in this case?

If they are not numbers, they are not interpreted as numbers. So, $a[0] is
the same as $a['0'], but different from $a["foo"].
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #9307 Updated: Numeric-looking arraykeys are forced to be integers

2001-03-06 Thread David Croft



So what about a string key that breaks when someone enters a string that
can be autoconverted. Zend turns it into a number and hey presto nothing
works any more. Can we have a construct to *force* it not to convert these
things?

On Tue, 6 Mar 2001, Stanislav Malyshev wrote:

 DC Even for array keys that are *not numbers*? How do I get a
 DC string for my array key in this case?

 If they are not numbers, they are not interpreted as numbers. So, $a[0] is
 the same as $a['0'], but different from $a["foo"].
 --
 Stanislav Malyshev, Zend Products Engineer
 [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115





-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: PHP 4.0 Bug #9307 Updated: Numeric-looking arraykeys are forced to be integers

2001-03-06 Thread Stanislav Malyshev

DC So what about a string key that breaks when someone enters a
DC string that can be autoconverted. Zend turns it into a number
DC and hey presto nothing works any more. Can we have a construct
DC to *force* it not to convert these things?

I don't get what you are talking about. Can you give me an example
(script)?
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




  1   2   >