[PHP-DEV] Re: [PHP-QA] 4.1.0RC4

2001-11-30 Thread Alexander Wirtz

>http://www.php.net/~zeev/php-4.1.0RC4.tar.gz
>
>The plan is to release Monday, unless a real earth quaker is found...

Builds and runs on
SuSE 7.3\
RedHat 7.1  - as CGI
SunOS 5.8   /

Details can be found on
http://fooassociates.com/phpqa/index.php?AlexanderWirtzBuilds4.1.0RC4

Regards
Alexander

-- 
| Alexander Wirtz   | eMail: [EMAIL PROTECTED]|
| web@ctive GmbH|   PDF 4 PHP http://sf.net/projects/pc4p/   |

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: 4.1.0RC4

2001-11-30 Thread Jobarr

Can some one tell me how to build this and the apache2 filter for windows
with Visual C++  6?

"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
5.1.0.14.2.20011201061139.01e573f8@localhost">news:5.1.0.14.2.20011201061139.01e573f8@localhost...
> http://www.php.net/~zeev/php-4.1.0RC4.tar.gz
>
> The plan is to release Monday, unless a real earth quaker is found...
>
> Zeev
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] 4.1.0RC4

2001-11-30 Thread Zak Greant

On November 30, 2001 09:12 pm, Zeev Suraski wrote:
> http://www.php.net/~zeev/php-4.1.0RC4.tar.gz
>
> The plan is to release Monday, unless a real earth quaker is found...

Builds and runs on SuSE 7.1 as CGI
See http://fooassociates.com/phpqa/index.php?ZakGreantBuilds4.1.0RC4

-- 
--zak

"We must be the change we wish to see." - M. K. Ghandi

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14308: mysql functions load twice (duplicate name)

2001-11-30 Thread php

From: [EMAIL PROTECTED]
Operating system: RH 7.2
PHP version:  4.0.6
PHP Bug Type: MySQL related
Bug description:  mysql functions load twice (duplicate name)

Humm, ? Operator error ? RH 7.2 SMP

PHP config:
./configure  --with-apache=../apache_1.x --with-mysql=/usr/local/
--enable-memory-limit=yes --enable-debug=no

Mysql config:
 ./configure  --with-client-ldflags=-all-static
--with-mysqld-ldflags=-all-static

Apache:
./configure \
"--with-layout=Apache" \
"--prefix=/etc/httpd" \
"--activate-module=src/modules/php4/libphp4.a" \
"--enable-module=php4" \

When httpd is started, get large list of mysql duplicate names such as:

"PHP Warning:  Function registration failed - duplicate name -
mysql_listfields in Unknown on line 0"

mysql continues to work, but other errors are not added to log file. It
looks like this is because an identical set of warnings are printed out
twice... which may have set the logging to be disabled??
-- 
Edit bug report at: http://bugs.php.net/?id=14308&edit=1


-- 
PHP Development Mailing List 
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] ldap_first_attribute() and ldap_next_attribute() broken in 4.1.0 RCs

2001-11-30 Thread Zeev Suraski

If it was broken for 6 months, it was broken in 4.0.6.  It will be broken 
in 4.1.0, it's not grounds for breaking a final RC...

Zeev

At 01:43 01/12/2001, Stig Venaas wrote:
>I was by accident looking at the ldap_first_attribute() code and
>realized that something was wrong. Turns out that it has been
>broken for 6 months without anyone noticing! I've done a lot of
>LDAP testing, but I've not been using ldap_first_attribute() and
>ldap_next_attribute(). I know accidents easily happens, but I
>wish people would test when they change things.
>
>I think the patch below fixes it. Could we apply the same patch to
>4.1.0? I don't think we can release 4.1.0 without these functions
>working, and this fix shouldn't affect anything but those functions.
>
>Stig
>
>- Forwarded message from Stig Venaas <[EMAIL PROTECTED]> -
>
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>Precedence: bulk
>list-help: 
>list-unsubscribe: 
>list-post: 
>Delivered-To: mailing list [EMAIL PROTECTED]
>From: "Stig Venaas" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: Fri, 30 Nov 2001 23:37:44 -
>Subject: [PHP-CVS] cvs: php4 /ext/ldap ldap.c
>
>venaas  Fri Nov 30 18:37:44 2001 EDT
>
>   Modified files:
> /php4/ext/ldap  ldap.c
>   Log:
>   ldap_first_attribute and ldap_next_attribute has been completely broken
>   for 6 months!! Fixed (I think), might be a memory leak there...
>
>
>Index: php4/ext/ldap/ldap.c
>diff -u php4/ext/ldap/ldap.c:1.107 php4/ext/ldap/ldap.c:1.108
>--- php4/ext/ldap/ldap.c:1.107  Thu Nov 29 15:26:20 2001
>+++ php4/ext/ldap/ldap.cFri Nov 30 18:37:43 2001
>@@ -22,7 +22,7 @@
> +--+
>   */
>
>-/* $Id: ldap.c,v 1.107 2001/11/29 20:26:20 venaas Exp $ */
>+/* $Id: ldap.c,v 1.108 2001/11/30 23:37:43 venaas Exp $ */
>  #define IS_EXT_MODULE
>
>  #ifdef HAVE_CONFIG_H
>@@ -232,6 +232,7 @@
> le_result = zend_register_list_destructors_ex(_free_ldap_result, 
> NULL, "ldap result", module_number);
> le_link = zend_register_list_destructors_ex(_close_ldap_link, 
> NULL, "ldap link", module_number);
> le_result_entry = zend_register_list_destructors_ex(NULL, NULL, 
> "ldap result entry", module_number);
>+   le_ber_entry = zend_register_list_destructors_ex(NULL, NULL, "ldap 
>ber entry", module_number);
>
> Z_TYPE(ldap_module_entry) = type;
>
>@@ -275,7 +276,7 @@
>
> php_info_print_table_start();
> php_info_print_table_row(2, "LDAP Support", "enabled" );
>-   php_info_print_table_row(2, "RCS Version", "$Id: ldap.c,v 1.107 
>2001/11/29 20:26:20 venaas Exp $" );
>+   php_info_print_table_row(2, "RCS Version", "$Id: ldap.c,v 1.108 
>2001/11/30 23:37:43 venaas Exp $" );
> php_info_print_table_row(2, "Total Links", maxl );
>
>  #ifdef LDAP_API_VERSION
>@@ -1001,7 +1002,7 @@
> if ((attribute = ldap_first_attribute(ld->link, 
> ldap_result_entry, &ber)) == NULL) {
> RETURN_FALSE;
> } else {
>-   ZEND_REGISTER_RESOURCE(return_value, ber, le_ber_entry);
>+   ZEND_REGISTER_RESOURCE(*berp, ber, le_ber_entry);
>
> RETVAL_STRING(attribute, 1);
>  #if ( LDAP_API_VERSION > 2000 ) || HAVE_NSLDAP || WINDOWS
>@@ -1032,7 +1033,7 @@
> if ((attribute = ldap_next_attribute(ld->link, ldap_result_entry, 
> ber)) == NULL) {
> RETURN_FALSE;
> } else {
>-   ZEND_REGISTER_RESOURCE(return_value, ber, le_ber_entry);
>+   ZEND_REGISTER_RESOURCE(*berp, ber, le_ber_entry);
>
> RETVAL_STRING(attribute, 1);
>  #if ( LDAP_API_VERSION > 2000 ) || HAVE_NSLDAP || WINDOWS
>
>
>
>--
>PHP CVS 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]
>
>- End forwarded message -
>
>--
>PHP Development Mailing List 
>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.1.0RC4

2001-11-30 Thread Zeev Suraski

http://www.php.net/~zeev/php-4.1.0RC4.tar.gz

The plan is to release Monday, unless a real earth quaker is found...

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14307: (cgi) $PHP_SELF has same value of $PATH_INFO

2001-11-30 Thread scpark

From: [EMAIL PROTECTED]
Operating system: Redhat 7.2
PHP version:  4.0.6
PHP Bug Type: Scripting Engine problem
Bug description:  (cgi) $PHP_SELF has same value of $PATH_INFO

In cgi mode of php 4.0.6.
$PHP_SELF was always same with $SCRIPT_NAME.$PATH_INFO before I upgrade my
cgi mode php. NOW, It has only $PATH_INFO value. 
Is this not bug? changed feature?
-- 
Edit bug report at: http://bugs.php.net/?id=14307&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #12463 Updated: set_attribute($attName, "0") does not add attributes

2001-11-30 Thread mfischer

ID: 12463
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: DOM XML related
Operating System: Win2K
PHP Version: 4.0.6
New Comment:

This is fixed already (at least, in CVS). Closing.

Previous Comments:


[2001-11-21 20:09:30] [EMAIL PROTECTED]

Can you try latest RC and see if the problem still exists

http://www.php.net/~zeev/php-4.1.0RC3.tar.gz

Feedback.




[2001-07-30 04:42:08] [EMAIL PROTECTED]

When I try to add an attribute with value "0" to a DomNode, like this:

$cNode->set_attribute("attributeName", "0");

The attribute isn't added, and worse, any attributes added to this node later won't be
added aswell. But this does only happen when the zero-valuead attribute isn't the 
first one added. 
JW
 




[2001-07-30 04:23:27] [EMAIL PROTECTED]

When I try to add an attribute with value "0" to a DomNode, like this:

$cNode->set_attribute("attributeName", "0");

The attribute isn't added, and worse, any attributes added to this node later won't be 
added aswell. I'll see if I can add a short reproducing script later.

JW
 





Edit this bug report at http://bugs.php.net/?id=12463&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #10994 Updated: DOMXML CDATA Node Bug

2001-11-30 Thread mfischer

ID: 10994
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Assigned
Bug Type: DOM XML related
Operating System: Winnt
PHP Version: 4.0.5
Old Assigned To: 
Assigned To: mfischer
New Comment:

Update: Fix is coming, assigned to me.

Btw, the syntax has changed since then, you'll have to use:

  print_r($arr[2]->children());

to see your CDATA node then.


Previous Comments:


[2001-11-22 03:36:00] [EMAIL PROTECTED]

Can you try with latest RC and see if it works

http://www.php.net/~zeev/php-4.1.0RC3.tar.gz

Feedback.




[2001-05-21 13:49:12] [EMAIL PROTECTED]

Hello Dear PHP Support.
I have compatability problem with PHP 4.04 - PHP 4.05, exactly in DOMXML (i mean) 
module.

This is piece of my code:

-

nodeset;

  
for($block_n=1; $block_nnodeset; 


for($blockset_n=1; $blockset_nnodeset;

$blockset_type = $myarr[0]->getattr("type");

//  

$obj3 = xpath_eval($ctx, 
"//DOC/BLOCKS/BLOCK[$block_n]/BLOCKSET[$blockset_n]/BLOCKSETELEMENT");
$arr3 = $obj3->nodeset; 

$blocksetelements = array();

for($blocksetelement_n=1; 
$blocksetelement_n"as"),array("s2"=>"a2"));

$blocksets[$blockset_type] = $blocksetelements;

}




$blocks[] = array_merge($block_vars, $blocksets);

}   



$blocks_arr = array("BLOCKS"=>$blocks);
$doc_v = array_merge($doc_vars, $blocks_arr);

}




function xml_parse_vars($ctx,$path) {

  $obj = xpath_eval($ctx, $path);
  $arr = $obj->nodeset;

  if($path == "//DOC/BLOCKS/BLOCK[1]/BLOCKSET[2]/BLOCKSETELEMENT[1]/VAR") {
  print_r($arr);
  }
  
for($x=0; $xgetattr("name");
$value = $arr[$x]->content;
  
$results[$name] = $value;

}

  return $results;

 } //function


XML_Def_Parse("kulichki.xml");

?>

---

This is "kulichki.xml":

--






KULICHKI.TV
Ïðîãðàììà òåëåïåðåäà÷ íà Kulichki
tv6.htm




  

Îáùèé áëîê














Êàíàë/äåíü






   
 

 














-


This script output in PHP 4.04 (it is right):

X-Powered-By: PHP/4.0.4
Content-type: text/html

Array
(
[0] => DomNode Object
(
[type] => 1
[name] => VAR
[content] => Êàíàë/äåíü
[node] => Resource id #24
)

[1] => DomNode Object
(
[type] => 1
[name] => VAR
[node] => Resource id #25
)

[2] => DomNode Object
(
[type] => 1
[name] => VAR
[content] => .*?{%%:day}. {%%:day} {%%:month}. 
{%%:channel}.*?.*?{%%:programs}
[node] => Resource id #26
)

[3] => DomNode Object
(
[type] => 1
[name] => VAR
[node] => Resource id #27

[PHP-DEV] °ê»Ú°·¨­­Ñ¼Ö³¡ «~½è«OÃÒ

2001-11-30 Thread xqww1nwx2y


°ê»Ú°·¨­­Ñ¼Ö³¡  «~½è«OÃÒ
   


T0:ºÖ§Q©e­û·|¡]·q½Ð¤½§G¡^
¨È¤O¤s¤j°·±d¥ð¶¢­Ñ¼Ö

¥@¶T°ê»Ú´LºaÀ] µØ¯Ç«Â¨q®Ç...§Y±N²{¨­!

¥þ¥x­º³Ð,¥þ¬Ù³q¦æ15®a(´LºaÀ]°£¥~), ¤£­­¦¸¼Æ¨Ï¥Î

§Y¤é°_¦Ü90¦~11¤ë30¤é¤î(°ê»Ú³q¦æ¥d­ì»ù45000¤¸)

¹ÎÅé³ø¦W  ¤jÀu´f

¤­¦~·|Äy Àu´f¥d

¯S»ù¨göt$20,000¤¸  ¡I¡I



¥þ°ê°ß¤@³q¹LISO9002°ê»Ú«~«O»{ÃÒ¤§°·¨­¤¤¤ß
1. ¥þ°ê³Ì¤j¡A¥þ¬Ù¤À³¡20®a¥H¤W
2. ¥þ°ê­º³Ð¡A¤@¥d³q¦æ¥þ¬Ù20®a¤À³¡¡A¤£­­¦¸¼Æ¨Ï¥Î
3. ·|­û¨î«×³Ì¶W­È¡A·|­û¥d¨Ï¥Î´Á­­ªø¹F60­Ó¤ë
4. »ù®æ³Ì¤½¹D¡A¨C¤ë¤ë¶O¥u»Ý1000¤¸ 

¡i´LºaÀ] ³] ³Æ ¤¶ ²Ð¡j
«Ç¤º±Ä¥ú·Å¤ô´åªa¦À . «ö¼¯¦À  /  ­«¶q°V½m°·¨­©Ð 
Ãý«ß½Òµ{¤£­­°ó¼Æ ¶O¥Î¥þ§K / ­¸½ü¦³®ñ±Ð«Ç \ ®à²y / «Ç¤º°j¤O²y
¨k¤k¤T·Å·x-¯N½c-»]®ð«Ç /  SPA¬ü®e°Ï / ¥ð¶¢À\ÆUµ¥µ¥

¡i¤À ³¡ ¤¶ ²Ð¡j
¥x¥_¡G«n´ä / ¥Ã©M / ¤T­« / ´°«n / ¯¸«e¤j¨È/ 
¤¤¤s / «°¤¤ / ¤½À] / ¤º´ò / ·s²ø / ªO¾ô
¥x¤¤¡G¤å¤ß / ¤¤´ä  ¥x«n¡G   °ª¶¯¡G




±M®×¸g¿ì : ³¯ «a ¦t  ¦æ°ÊGSM :0936-588-338
   
°ÑÆ[¦n§¤j¬Û°e Åwªï¨Ó¹q¹w¬ù°ÑÆ[ (°e§¹¬°¤î)



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #10936 Updated: DOMXML crash with CDATA

2001-11-30 Thread mfischer

ID: 10936
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Assigned
Bug Type: DOM XML related
Operating System: Win2K Pro
PHP Version: 4.0.5
Old Assigned To: 
Assigned To: mfischer
New Comment:

Update: Fix is coming, assigned to me.

Previous Comments:


[2001-11-21 19:39:01] [EMAIL PROTECTED]

Does this problem still exists with 4.0.6 from php.net?

Feedback.



[2001-05-17 18:31:59] [EMAIL PROTECTED]

Not in the binaries in 
http://www.php.net/do_download.php?download_file=php-4.0.5-Win32.zip&source_site=www.php.net.


The children property returns NULL in all cases. The children method works correctly 
unless one of the children is a CDATA node.

The source code in 
http://www.php.net/do_download.php?download_file=php-4.0.5.tar.gz&source_site=www.php.net
 shows children as a method and not as a property.



[2001-05-17 17:59:27] [EMAIL PROTECTED]

domxml has changed from children being a method to being a member. Try $children = 
$root->children



[2001-05-17 13:21:56] [EMAIL PROTECTED]

I am running the latest Win32 binaries from the php.net download page. I am using the 
ISAPI module on IIS5. In php.ini I enabled DOMXML by uncommenting the appropriate 
line.

Calling the children function on a node that has a CDATA node as a child results in an 
access violation. Here's a script that reproduces the problem:

$doc = xmldocfile('http://tbhbuilding.blogspot.com');
$root = $doc->root();
$children = $root->children();
$children = $children[1]->children();
print_r($children[1]->children());

I would have generated a gdb backtrace if the instructions for doing so explained how 
to do it with the ISAPI module.






Edit this bug report at http://bugs.php.net/?id=10936&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] PHP Manual

2001-11-30 Thread l0t3k

i just downloaded the Windows PHP manual, and all i can say is

-- DAMN --

are you sure no one gets paid to do this  ???

kudos to the doc team for what has to be the finest user docs in open
source.

l0t3k



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #10667 Updated: xmltree function cause memory leak

2001-11-30 Thread mfischer

ID: 10667
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Assigned
Bug Type: DOM XML related
Operating System: Linux 2.2.16
PHP Version: 4.0.5
Old Assigned To: 
Assigned To: mfischer
New Comment:

Update: CDATA should already work with current CVS; some minor fixes are coming.

Assigned to me.

Previous Comments:


[2001-11-22 03:31:02] [EMAIL PROTECTED]

Can you try with latest RC and see if it works

http://www.php.net/~zeev/php-4.1.0RC3.tar.gz

Feedback.





[2001-05-04 11:29:00] [EMAIL PROTECTED]

My code:

---
version;
?>
--

The file.xml  is:
--


























5


























5


-


When I start apache I have:

20562 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20563 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20564 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20565 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20566 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20567 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20568 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20569 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20570 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20571 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20572 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20573 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20574 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20575 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf
20576 ?S  0:00  3   739  8700 4448  1.7 /bin/httpd -d / -f /conf

After I reloaded my php script for 75 times, the situation changed to:

20562 ?S  0:00 97   739  9892 6004  2.3 /bin/httpd -d / -f /conf
20563 ?S  0:00104   739  9276 5388  2.1 /bin/httpd -d / -f /conf
20564 ?S  0:00102   739  9120 5240  2.0 /bin/httpd -d / -f /conf
20565 ?S  0:00 94   739 10048 6160  2.4 /bin/httpd -d / -f /conf
20566 ?S  0:00 94   739  9740 5852  2.2 /bin/httpd -d / -f /conf
20567 ?S  0:00 90   739  9272 5376  2.0 /bin/httpd -d / -f /conf
20568 ?S  0:00 94   739  9428 5552  2.1 /bin/httpd -d / -f /conf
20569 ?S  0:00 95   739  9584 5704  2.2 /bin/httpd -d / -f /conf
20570 ?S  0:00 90   739 10048 6152  2.3 /bin/httpd -d / -f /conf
20571 ?S  0:00 90   739  9272 5376  2.0 /bin/httpd -d / -f /conf
20572 ?S  0:00 99   739  9120 5240  2.0 /bin/httpd -d / -f /conf
20573 ?S  0:00100   739  9892 6004  2.3 /bin/httpd -d / -f /conf
20574 ?S  0:00 95   739  9892 6012  2.3 /bin/httpd -d / -f /conf
20575 ?S  0:00 93   739  9736 5848  2.2 /bin/httpd -d / -f /conf
20576 ?S  0:00 94   739  9428 5540  2.1 /bin/httpd -d / -f /conf

I also have problems when I try to access  a CDATA  field's content.
For example, when I call the children() method of a node who have 
a child of type CDATA,  my server receives a  Segmentation fault signal.







Edit this bug report at http://bugs.php.net/?id=10667&edit=1


-- 
PHP Development Mailing List 

[PHP-DEV] Re: Sessions proposal

2001-11-30 Thread J Smith


I assume you mean where the user is geographically, where timezones are a 
factor. But still, what difference does it make where the user is? If you 
track the login time using the server's localtime, it doesn't matter what 
timezone they're in. 

Not the most elegant solution, but it's better than nothing.

J


André NæSs wrote:

> 
> Maybe I was unclear. The problem is that to allow for 2 hour timeouts I
> need to have gc_maxlifetime set to 2 hours, but for 99,9% of all session I
> don't need than 15 minutes gc_maxlifetime since they have a cookie
> lifetime of 15 minutes.
> 
> Also, I can't log the user out after 15 minutes (it's better to use
> cookie_lifetime for that), I haven't got any idea of where he is, so
> storing the login time as a session variable won't let me change the
> gc_maxlifetime.
> 
> André Næss
> 
> 
>>

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] ldap_first_attribute() and ldap_next_attribute() broken in 4.1.0 RCs

2001-11-30 Thread Stig Venaas

I was by accident looking at the ldap_first_attribute() code and
realized that something was wrong. Turns out that it has been
broken for 6 months without anyone noticing! I've done a lot of
LDAP testing, but I've not been using ldap_first_attribute() and
ldap_next_attribute(). I know accidents easily happens, but I
wish people would test when they change things.

I think the patch below fixes it. Could we apply the same patch to
4.1.0? I don't think we can release 4.1.0 without these functions
working, and this fix shouldn't affect anything but those functions.

Stig

- Forwarded message from Stig Venaas <[EMAIL PROTECTED]> -

Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: 
list-unsubscribe: 
list-post: 
Delivered-To: mailing list [EMAIL PROTECTED]
From: "Stig Venaas" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Fri, 30 Nov 2001 23:37:44 -
Subject: [PHP-CVS] cvs: php4 /ext/ldap ldap.c  

venaas  Fri Nov 30 18:37:44 2001 EDT

  Modified files:  
/php4/ext/ldap  ldap.c 
  Log:
  ldap_first_attribute and ldap_next_attribute has been completely broken
  for 6 months!! Fixed (I think), might be a memory leak there...
  
  
Index: php4/ext/ldap/ldap.c
diff -u php4/ext/ldap/ldap.c:1.107 php4/ext/ldap/ldap.c:1.108
--- php4/ext/ldap/ldap.c:1.107  Thu Nov 29 15:26:20 2001
+++ php4/ext/ldap/ldap.cFri Nov 30 18:37:43 2001
@@ -22,7 +22,7 @@
+--+
  */
  
-/* $Id: ldap.c,v 1.107 2001/11/29 20:26:20 venaas Exp $ */
+/* $Id: ldap.c,v 1.108 2001/11/30 23:37:43 venaas Exp $ */
 #define IS_EXT_MODULE
 
 #ifdef HAVE_CONFIG_H
@@ -232,6 +232,7 @@
le_result = zend_register_list_destructors_ex(_free_ldap_result, NULL, "ldap 
result", module_number);
le_link = zend_register_list_destructors_ex(_close_ldap_link, NULL, "ldap 
link", module_number);
le_result_entry = zend_register_list_destructors_ex(NULL, NULL, "ldap result 
entry", module_number);
+   le_ber_entry = zend_register_list_destructors_ex(NULL, NULL, "ldap ber entry", 
+module_number);
 
Z_TYPE(ldap_module_entry) = type;
 
@@ -275,7 +276,7 @@
 
php_info_print_table_start();
php_info_print_table_row(2, "LDAP Support", "enabled" );
-   php_info_print_table_row(2, "RCS Version", "$Id: ldap.c,v 1.107 2001/11/29 
20:26:20 venaas Exp $" );
+   php_info_print_table_row(2, "RCS Version", "$Id: ldap.c,v 1.108 2001/11/30 
+23:37:43 venaas Exp $" );
php_info_print_table_row(2, "Total Links", maxl );
 
 #ifdef LDAP_API_VERSION
@@ -1001,7 +1002,7 @@
if ((attribute = ldap_first_attribute(ld->link, ldap_result_entry, &ber)) == 
NULL) {
RETURN_FALSE;
} else {
-   ZEND_REGISTER_RESOURCE(return_value, ber, le_ber_entry);
+   ZEND_REGISTER_RESOURCE(*berp, ber, le_ber_entry);
 
RETVAL_STRING(attribute, 1);
 #if ( LDAP_API_VERSION > 2000 ) || HAVE_NSLDAP || WINDOWS
@@ -1032,7 +1033,7 @@
if ((attribute = ldap_next_attribute(ld->link, ldap_result_entry, ber)) == 
NULL) {
RETURN_FALSE;
} else {
-   ZEND_REGISTER_RESOURCE(return_value, ber, le_ber_entry);
+   ZEND_REGISTER_RESOURCE(*berp, ber, le_ber_entry);
 
RETVAL_STRING(attribute, 1);
 #if ( LDAP_API_VERSION > 2000 ) || HAVE_NSLDAP || WINDOWS



-- 
PHP CVS 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]

- End forwarded message -

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14306: Need a something to pass to use default function values

2001-11-30 Thread mikep

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.1.0
PHP Bug Type: Feature/Change Request
Bug description:  Need a something to pass to use default function values

I would like a way to pass something into a function and have it use the
default values.

For eg., if I have the function
function test( $value, $value1=1, $value2=2 )

and I call it like test( "value", "", "2" ) I think it should use 1 for
$value1.  It currently does not, but I'd like to be able to pass something
in to make it use the default value, like:
test( "value", NULL, "2" )
I know you can rewrite the function to test for $value1="", but I'd rather
not do that.
-- 
Edit bug report at: http://bugs.php.net/?id=14306&edit=1


-- 
PHP Development Mailing List 
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] zend_hash and it's keys + domxml

2001-11-30 Thread Markus Fischer

add_property_*() is used.

- Markus

On Fri, Nov 30, 2001 at 07:23:29PM +0100, Krzysztof Jarecki wrote : 
> Hi all ;)
> 
> I was just wondering why this line doesn't work. It's an extract from
> domxml.c (slightly changed):
> 
> if (zend_hash_find(id->value.obj.properties, "doc", sizeof("doc"), (void
> **)&tmp) == FAILURE) {
>php_error(E_WARNING, "unable to find my handle property");
> 
> This is said to be working under php 4.0.6 and I am using a cvs version of
> domxml.c and domxml.h
> 
> Exactly this one: php_domxml.c,v 1.75 2001/09/19 02:24:05 joey Exp
> 
> I am also curios about the keys in the hash tables.
> How and where can I find which keys are added into the hash tables?
> Maybe it's not "doc"... in the domxml extensio there is also "children" key
> and a few others probably.
> 
> Where can I find these?
> I was looking for some zend_hash_update, or zend_hash_add functions but
> unfortunately it doesn't help ;(
> 
> Thank for any feedback
> 
> Chris Jarecki
> 
> 
> 
> -- 
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14218 Updated: using pspell functions cause apache to Abort

2001-11-30 Thread vlad

ID: 14218
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Pspell related
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.0.6
New Comment:

thanks for offering access to a freebsd box... i do not think that's going to help a 
lot though 'cause I won't have time to get to it soon (overtime job and getting 
married at the same time, ouch!).

I'll look more into it later, but if someone with more experience with freebsd can 
look into it, that would be great. I am no UNIX guru, by any means. I don't even know 
why your apache doesn't give you a core. No, I do not know whether mod_gzip or zend 
optimizer contribute, I would imagine, it shouldn't contribute much, but you could try 
to eliminate those two possibilities by not using them and see if that helps.

In short, does anyone feel up to picking this bug up? It seems like it's something 
simple yet fundamental. I lack the time and knowledge. Otherwise I'll get back to it a 
bit later (probably ver 4.2 or so)

Previous Comments:


[2001-11-29 19:22:58] [EMAIL PROTECTED]

Answers:

1. Built pspell from scratch again, uninstalled and reinstalled, su'ed to nobody, 
executed example-c with success, ran a few lookups.  Cut and paste:
 --> su - nobody -c id
uid=65534(nobody) gid=65534(nobody) groups=65534(nobody)
--> su - nobody -c "`pwd`/example-c en"
Using: en---aspell

Type "h" for help.

s recieve

receive
receiver
Recife
relieve
received
receives
[...]

2. I wasn't sure what the pws format looked like, so I threw out the personal one and 
just tried pspell_new("en");, with no luck.  I put an echo and exit before the 
pspell_new, and it works fine.  Put an echo and an exit AFTER the pspell_new call, and 
it "Abort"s the apache thread. 
[Thu Nov 29 19:10:42 2001] [notice] child pid 79097 exit signal Abort trap (6)

Could it be that we're running mod_gzip?  I wouldn't think so, but we are using it.  
We are also using the Zend PHP Optimizer.

I'm happy to install PHP on a FreeBSD box and give you access if you want to play, 
though it wouldn't be the box I'm having trouble with, and I haven't tested the pspell 
failure on that install.




[2001-11-29 18:30:05] [EMAIL PROTECTED]

hmmm... It does not crash, it does not let you have a backtrace, yet it doesn't work 
either. And you seem to have followed most of the installation instructions and have 
recent versions of everything. On top of that I know nothing concerning FreeBSD, and 
do not have a FreeBSD machine.

Couple questions:

1. Can you execute and use example-c as nobody (I know you executed it, period, but 
probably with more permissions, so this might not work.

2. Is /usr/share/dict/acmovies is a *file* (not a dir) in the .pws format? I know, 
it's kinda stupid to askm but just in case...

Besides that, I have no clues right now. Any ideas? anyone?




[2001-11-25 15:00:29] [EMAIL PROTECTED]

Sorry -- That script has an extra close curly brackets that isn't really there.  
Please remove that to get desired crashing effect.

Also, http://www.adcritic.com/spellcheck.php is the offending script.  In IE, I get 
the "The page cannot be displayed."  Telnetting gets me this:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /spellcheck.php?q=foo HTTP/1.0

Connection closed by foreign host.

where if I leave the query blank (it doesn't run the offending pspell function), I 
get:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /spellcheck.php HTTP/1.0

HTTP/1.1 200 OK
Date: Sun, 25 Nov 2001 19:59:49 GMT
Server: Apache/1.3.22 (Unix) mod_gzip/1.3.19.1a PHP/4.0.6
X-Powered-By: PHP/4.0.6
Set-Cookie: ADCRITICPHPSID=188feaf823cbb54ca102332da63464d8; expires=Sat, 23-Feb-02 
19:59:49 GMT; path=/; domain=.adcritic.com
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html




Connection closed by foreign host.

If q is empty, the script isn't executed (if !empty($q)) etc...




[2001-11-25 14:57:01] [EMAIL PROTECTED]

Script:
   $q = "foo";
   $pl = pspell_new_personal("/usr/share/dict/acmovies","en");
   $sug = pspell_suggest($pl,$q);
   if (count($sug)>0) {
  echo "Suggestions:";
  while(list(,$val)=each($sug)) {
 echo "{$val}";
  }
   } else {
  echo "No matches.";
   }
}

Script runs when pspell_new_personal is not included (commented out).  fails with 
pspell_new function as well.

Configure line:
 './configure' '--with-apxs=/usr/local/sbin/apxs' 
'--with-config-file-path=/usr/local/etc' '--enable-versioning' '--with-syste

Re: [PHP-DEV] Re: [PHP-QA] PHP 4.1.0RC4

2001-11-30 Thread Egon Schmid

From: "Sebastian Bergmann" <[EMAIL PROTECTED]>

> Tobias Schenck wrote:
> > Short time after the announcement just disappeared. I don't know
about
> > the traffic on php-center.de or phpwelt.de (was on one of the
sites)
> > but quite a couple of people not tracking php.dev might have
> > downloaded it.
>
>   PHP-Center.de, for which I am a author and editor, had at no
time a
>   news bulleting and / or a download link for PHP 4.1.0 online.
>
>   I don't know about phpwelt.de (I never visit that one...), but
>   PHP-Homepage.de had a news bulleting regarding PHP 4.1.0 online.

DWP is www.dynamicwebpages.de.

-Egon


-- 
PHP Development Mailing List 
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-QA] PHP 4.1.0RC4

2001-11-30 Thread Egon Schmid

From: "Sebastian Bergmann" <[EMAIL PROTECTED]>

> Tobias Schenck wrote:
> > Short time after the announcement just disappeared. I don't know
about
> > the traffic on php-center.de or phpwelt.de (was on one of the
sites)
> > but quite a couple of people not tracking php.dev might have
> > downloaded it.
>
>   PHP-Center.de, for which I am a author and editor, had at no
time a
>   news bulleting and / or a download link for PHP 4.1.0 online.
>
>   I don't know about phpwelt.de (I never visit that one...), but
>   PHP-Homepage.de had a news bulleting regarding PHP 4.1.0 online.

Oh, have you seen the subject? RC4 have been released after your
posting. I hope Wolfgang or Matthias will make it public on DWP:)
soon.

-Egon


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14296 Updated: Undeclared variables and isset()

2001-11-30 Thread v . puttrich

ID: 14296
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
New Comment:

What was the default in "php.ini-dist" for version 4.0.5?

I always leave the error_reporting in the ini file as it is.
The reason for that is, I want the same behaviour of PHP on all servers I use.
I didn't know that i can't rely on the default setting.

my error_reporting is set to E_ALL.

Thanks for the hint




Previous Comments:


[2001-11-30 12:28:50] [EMAIL PROTECTED]

Not a bug.




[2001-11-30 04:36:45] [EMAIL PROTECTED]

looks like you have set error_reporting to E_ALL
while you had E_ALL & ~E_NOTICE before?

maybe by using php.ini-recommended as template
for php.ini with 4.0.6 while using php.ini-dist
for the former versions?



[2001-11-30 04:15:44] [EMAIL PROTECTED]


SYSTEM:
I use PHP 4.0.6 on Win2k pro with Apache 1.3.22 win
Loaded modules don't seem to make a difference for the described behaviour.

DESCRIPION:
Let's say we have a PHP script, the retrieves some variables via HTTP post or get. And 
the variables, passed to the script, have different names each time.
Usually we would use "isset($variable)" to check if it exists. In most cases we need 
to check the content of the variable too. So it would be nice to do that in one step.

The script of the following examples retrieved $var1 or $var or both of them via HTTP.

EXAMPLE 1:
// This would be the usual way i guess
if(isset($var1)){
  ...
}
if(isset($var2)){
  ...
}

EXAMPLE 2:
// This has been possible with PHP 3.xx - 4.0.5
// without previously checking for existence 
// of $var1/$var2
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}

EXAMPLE 3:
// With PHP 4.0.6 we would have to do this:
if(!isset($var1)){ // is NOT declared?
  $var1 = "";
}
if(!isset($var2)){ // is NOT declared?
  $var2 = "";
}
// first we had to declare them, now we can use them
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}


I wonder if this new behaviour is a bug or a feature?
Or why can't I find info about it in the changes list if it's a feature?

Please send your answer to: [EMAIL PROTECTED]

Thank you!

Volker Puttrich






Edit this bug report at http://bugs.php.net/?id=14296&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14295 Updated: Scope of globals has changed

2001-11-30 Thread v . puttrich

ID: 14295
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
New Comment:

EXAMPLE:
// Main script

// The global variables are available in this script

include("form.inc.php");

  ...
// End main script

// File: form.inc.php

// The global variables from the main script are not available here


  [form]

// End file: form.inc.php


Previous Comments:


[2001-11-30 12:25:30] [EMAIL PROTECTED]

Please include short example scripts here.




[2001-11-30 03:51:40] [EMAIL PROTECTED]

The following bug or feature (not yet sure what it is ;)) is related to the scope of 
global variables.

SYSTEM:
I use PHP 4.0.6 on Win2k pro as i downloaded it from this web site. 
The loading of extra modules does not change the described behaviour.
The Server API is Apache (Apache V. 1.3.22 win)

PHP.INI:
register_globals and register_argc_argv is ON


DESCRIPTION:
I have the global variable $PHP_SELF.
Now i include a file where I want to use $PHP_SELF.
Within the included file, $PHP_SELF is unknown (it has lost it's global state), and i 
have to declare it global again.
This appears for any other global variables too, $PHP_SELF is just an example-
This behaviour seems to be new to PHP 4.0.6, because i didn't have the problem with 
4.0.5.






Edit this bug report at http://bugs.php.net/?id=14295&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14299 Updated: explode() case sensitivity.

2001-11-30 Thread philip

ID: 14299
Updated by: philip
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.0.6
New Comment:

Strings are case sensitive.  Kinda like: if ($var == 'Bar') will return false if $var 
= 'bar'. 

Maybe because explode() is such a commonly used function, this could be mentioned here 
(that it's case sensitive).  But doing so may open up a large can of worms (having to 
document this everywhere).  I vote -.5 on implementing this.

At first glance I don't see "strings being case sensitive" mention in the types.string 
section, maybe it should be.

Previous Comments:


[2001-11-30 11:01:44] [EMAIL PROTECTED]

I recently added a note to http://www.php.net/explode and was informed that I should 
probably post it here.

Original Note:
I'm not sure if this is intentional, but there is no indication whether explode() is 
case insensitive. I ended up having to convert my strings and keywords to lowercase 
using strtolower() in order to do this. I'm using 4.0.4, FWIW.

I don't care one way or another if this is a bug or a documentation error since I was 
able to work around it, but I think other people may get confused when it fails to 
explode because there's no info about case sensitivity.

Thanks,
Stephen VanDyke
[EMAIL PROTECTED]





Edit this bug report at http://bugs.php.net/?id=14299&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14200 Updated: remote navigation problem

2001-11-30 Thread cquadalti

ID: 14200
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: *General Issues
Operating System: Windows XP Pro
PHP Version: 4.0.6
New Comment:

I have verified but i don't have any firewall installed.
Other people have same problem. I don't know why this problem happens, I think I've 
read all possible news about but I don't have found any solution.
Have you replicated this problem in lab?
I hope in 4.1.0 release  

Previous Comments:


[2001-11-27 10:49:23] [EMAIL PROTECTED]

By default the "firewall" is not enabled.

But JIC you can check by doing this (may be faster way)

Control Panel->Network Connections
  Right Click on Network Bridge
  Choose Properties
  Choose TCP/IP From Items List
  Click Properties
  Click Advanced
  Click Options
  Highlight TCP/IP Filtering
  Click Properites
  Either Allow Port 80 if Filtering is enabled and Port 80 is blocked or disable 
filtering.

-Chris
  
  



[2001-11-27 10:22:47] [EMAIL PROTECTED]

I might be mistaken, but AFAIK you point Apache via httpd.conf to php4apache.dll. You 
can put that dll anywhere you want, as long as Apache knows the right path.
php4ts.dll on the contrairy, should be located in your windows/system32 directory.

But I don't think that solves your problem. I think the problem is that XP has some 
kind of firewall built in, which probably denies any incoming connections. You should 
open port 80 somewhere in your controlpanel... don't ask my where as I don't have XP 
yet...



[2001-11-26 14:48:18] [EMAIL PROTECTED]

Try the new 4.1.0 release which will be available withing a day or two.

Feedback.



[2001-11-26 14:17:08] [EMAIL PROTECTED]

I have overwritten php4apache.dll with new version...but apache tell me "i can't find 
php4apache.dll" (it can't use new file) I have also tried to insert php4apache in 
system32 and windows directories but doesn't work!
Where is the problem? 



[2001-11-24 07:48:56] [EMAIL PROTECTED]

Put your php4apche.dll in the same directory as apache (might work) or in the sytem32 
directory (should work).

Feedback.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14200


Edit this bug report at http://bugs.php.net/?id=14200&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14304 Updated: str_replace unable to match search string

2001-11-30 Thread bajolet

ID: 14304
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Operating System: Linux php3-2 2.4.7 #1 Thu Aug 9
PHP Version: 4.0.6
New Comment:

Sorry, i forgot :
All the application in dowloadable at : http://phpdig.toiletoine.net/phpdig_1_4_3.zip

Previous Comments:


[2001-11-30 13:40:34] [EMAIL PROTECTED]

Summary :
A function works well on php 4.0.5 and enters an infinite loop on php 4.0.6.

Function entering in infinite loop :
The purpose of this function is to parse a template containing some tags, line by 
line, and replace them by values contained in the $t_strings array.

The input can be :


i think the str_replace() function don't replace anything ; the while statment stays 
always true, etc...

function  parse_phpdig_tags($line,$t_strings)
{
while(eregi('',$line,$regs))

 {
 //links with images
 if ($regs[2])
 {
 if ($regs[3] && $t_strings[$regs[1]])
 {
 if (ereg('^http',$t_strings[$regs[1]]))
 $target = ' target="_blank"';
 else
 $target = '';

 $replacement = '';
 }
 else
 {
 $replacement = '';
 }
 $line = str_replace($regs[0],$replacement,$line);
 }
 else
 {
 $line = str_replace($regs[0],$t_strings[$regs[1]],$line);
 }
 }

   return $line;
}

Configuration not working (php 4.0.6) :
 '../configure' '--prefix=/usr' '--prefix=/usr' '--with-regex=system' 
'--enable-force-cgi-redirect' '--with-config-file-path=/etc/php4/cgi' 
'--disable-rpath' '--disable-pear' '--enable-memory-limit' '--enable-calendar' 
'--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2' '--with-ndbm' 
'--enable-exif' '--enable-filepro' '--with-gettext' '--enable-track-vars' 
'--enable-trans-sid' '--disable-debug' '--disable-static' '--with-mm' 
'--with-pcre-regex=/usr' '--enable-shmop' '--enable-sockets' '--with-xml=/usr' 
'--with-expat-dir=/usr' '--with-zlib' '--enable-email' '--disable-posix' 
'--without-mysql' '--without-sybase-ct'

Configuration working (php 4.0.5) :
'./configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-pgsql=/usr/local/pgsql' 
'--with-ldap' '--with-openssl' '--with-domxml' '--with-bcmath' '--enable-track-vars' 
'--with-gd=../gd-1.8.4' '--enable-freetype-4bit-antialias-hack' '--with-mysql' 
'--with-jpeg-dir=../jpeg-6b' '--with-png-dir=../libpng-1.0.12' 
'--with-freetype-dir=../freetype-2.0.4' '--with-zlib-dir=../zlib' 
'--with-sablot=SHARED' '--enable-bcmath' '--enable-ftp' '--enable-sockets' 
'--enable-magic-quotes' '--enable-versioning'






Edit this bug report at http://bugs.php.net/?id=14304&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14304: str_replace unable to match search string

2001-11-30 Thread bajolet

From: [EMAIL PROTECTED]
Operating system: Linux php3-2 2.4.7 #1 Thu Aug 9 
PHP version:  4.0.6
PHP Bug Type: Strings related
Bug description:  str_replace unable to match search string

Summary :
A function works well on php 4.0.5 and enters an infinite loop on php
4.0.6.

Function entering in infinite loop :
The purpose of this function is to parse a template containing some tags,
line by line, and replace them by values contained in the $t_strings
array.

The input can be :


i think the str_replace() function don't replace anything ; the while
statment stays always true, etc...

function  parse_phpdig_tags($line,$t_strings)
{
while(eregi('',$line,$regs))

 {
 //links with images
 if ($regs[2])
 {
 if ($regs[3] && $t_strings[$regs[1]])
 {
 if (ereg('^http',$t_strings[$regs[1]]))
 $target = ' target="_blank"';
 else
 $target = '';

 $replacement = '';
 }
 else
 {
 $replacement = '';
 }
 $line = str_replace($regs[0],$replacement,$line);
 }
 else
 {
 $line =
str_replace($regs[0],$t_strings[$regs[1]],$line);
 }
 }

   return $line;
}

Configuration not working (php 4.0.6) :
 '../configure' '--prefix=/usr' '--prefix=/usr' '--with-regex=system'
'--enable-force-cgi-redirect' '--with-config-file-path=/etc/php4/cgi'
'--disable-rpath' '--disable-pear' '--enable-memory-limit'
'--enable-calendar' '--enable-bcmath' '--with-bz2' '--enable-ctype'
'--with-db2' '--with-ndbm' '--enable-exif' '--enable-filepro'
'--with-gettext' '--enable-track-vars' '--enable-trans-sid'
'--disable-debug' '--disable-static' '--with-mm' '--with-pcre-regex=/usr'
'--enable-shmop' '--enable-sockets' '--with-xml=/usr'
'--with-expat-dir=/usr' '--with-zlib' '--enable-email' '--disable-posix'
'--without-mysql' '--without-sybase-ct'

Configuration working (php 4.0.5) :
'./configure' '--with-apxs=/usr/local/apache/bin/apxs'
'--with-pgsql=/usr/local/pgsql' '--with-ldap' '--with-openssl'
'--with-domxml' '--with-bcmath' '--enable-track-vars'
'--with-gd=../gd-1.8.4' '--enable-freetype-4bit-antialias-hack'
'--with-mysql' '--with-jpeg-dir=../jpeg-6b'
'--with-png-dir=../libpng-1.0.12' '--with-freetype-dir=../freetype-2.0.4'
'--with-zlib-dir=../zlib' '--with-sablot=SHARED' '--enable-bcmath'
'--enable-ftp' '--enable-sockets' '--enable-magic-quotes'
'--enable-versioning'

-- 
Edit bug report at: http://bugs.php.net/?id=14304&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14303: httpd threads hang with large data structures

2001-11-30 Thread Darren . Gamble

From: [EMAIL PROTECTED]
Operating system: Redhat 7.2
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  httpd threads hang with large data structures

I've had a lot of problems recently with PHP cleaning up properly after
using large data structures.

A sample script is included:

$huge_array = array();
for ( $i=0 ; $i<= 8000 ; $i++ ) {
  foreach (array("cn" , "uid" , "sn" , "givenName" , "attr1" , "attr2" ,
"attr3") as $j ) {
for ( $k=0 ; $k<= 50 ; $k++ ) { 
  $huge_array[$i][$j][$k] = rand(0,1)."value";
}
  }
}

The script executes normally, but the httpd thread remains afterwards,
consuming memory and CPU.  It appears to need a kill -9 to make it finally
die.  If enough of these are run, all of the child processes of apache get
tied up, preventing it from serving any more requests.  At this point the
threads have to be killed and the server restarted.

I've also encountered similar problems with storing the results of a large
ldap_get_entries(), although the behavior of the above script suggests that
the problem is not actually with the LDAP function.  Reducing the size of
the query incrementally reveals that there seems to be a "breaking point"
where this behavior begins.

httpd also logs that it has problems terminating its child processes:

[warn] child process 9541 still did not exit, sending a SIGTERM

I'm running php-4.0.6-7 under apache-1.3.20-16, all Redhat 7.2 RPMs, with
the default configuration.
-- 
Edit bug report at: http://bugs.php.net/?id=14303&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] zend_hash and it's keys + domxml

2001-11-30 Thread Krzysztof Jarecki

Hi all ;)

I was just wondering why this line doesn't work. It's an extract from
domxml.c (slightly changed):

if (zend_hash_find(id->value.obj.properties, "doc", sizeof("doc"), (void
**)&tmp) == FAILURE) {
   php_error(E_WARNING, "unable to find my handle property");

This is said to be working under php 4.0.6 and I am using a cvs version of
domxml.c and domxml.h

Exactly this one: php_domxml.c,v 1.75 2001/09/19 02:24:05 joey Exp

I am also curios about the keys in the hash tables.
How and where can I find which keys are added into the hash tables?
Maybe it's not "doc"... in the domxml extensio there is also "children" key
and a few others probably.

Where can I find these?
I was looking for some zend_hash_update, or zend_hash_add functions but
unfortunately it doesn't help ;(

Thank for any feedback

Chris Jarecki



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14302: self:: Accessing methods from within methods without an instance

2001-11-30 Thread ivan . lamouret

From: [EMAIL PROTECTED]
Operating system: any
PHP version:  4.0.6
PHP Bug Type: Feature/Change Request
Bug description:  self:: Accessing methods from within methods without an instance

When inside a class method, there is no "denormalised" way to get at other
methods "statically" i.e.:

class foo(){
function bar(){
// do not use $this;
}
function otherbar(){
foo::bar();//<--- allow self::bar()
}
}

foo::otherbar();

If foo was an extension of some other class foobase, it could get at the
foobase::methods with the "parent::" construct. In other words to get at my
parent's method I do not need to know its name, but if I am not an instance
I can not get at my own methods without giving my name. 

Since you can call a class method without an instance, this seems a natural
extension of php's ::

Thank you all
-- 
Edit bug report at: http://bugs.php.net/?id=14302&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14301: printer_list don't lists the local not shared printers

2001-11-30 Thread joergklein

From: [EMAIL PROTECTED]
Operating system: WinXP ger
PHP version:  4.0.6
PHP Bug Type: Unknown/Other Function
Bug description:  printer_list don't lists the local not shared printers

Hi

I tried out the printer_list funktion:
I am using WinXP Pro german not connected to a network
with 2 Printers installed locally not shared.



When I use the enumtype PRINTER_ENUM_LOCAL the function don't return
anything, but when I share one printer the function lists this shared
printer, but I should list both printers when there are not shared.
With enumtype PRINTER_ENUM_LOCAL | PRINTER_ENUM_SHARED the function lists
correct only the shared local printers.

-- 
Edit bug report at: http://bugs.php.net/?id=14301&edit=1


-- 
PHP Development Mailing List 
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 #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread Jani Taskinen


You have to say 'please' :)

--Jani


On Fri, 30 Nov 2001, Markus Fischer wrote:

>On Fri, Nov 30, 2001 at 07:23:39PM +0200, Jani Taskinen wrote :
>> Ask sterling about this. IMO, it's good as it is now.
>
>Asking sterling? It's more likely that I win a million than I
>get an answer from sterling 8-
>
>- Markus
>


-- 
PHP Development Mailing List 
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 #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread Markus Fischer

On Fri, Nov 30, 2001 at 07:23:39PM +0200, Jani Taskinen wrote : 
> Ask sterling about this. IMO, it's good as it is now.

Asking sterling? It's more likely that I win a million than I
get an answer from sterling 8-

- Markus

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14297 Updated: CPU LOOP

2001-11-30 Thread sniper

ID: 14297
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Old Bug Type: *General Issues
Bug Type: Scripting Engine problem
Operating System: RH6.2
PHP Version: 4.0.6
New Comment:

Add some nice little script here which can be used to reproduce this.
As it's like looking for a needle in the haystack  otherwise.


Previous Comments:


[2001-11-30 10:11:29] [EMAIL PROTECTED]

Is anyone here psycic cause I sure cant tell what is causing PHP to go into 100% loop, 
perhaps we can have a bit more information about when it happens and what your doing 
when it happens?



[2001-11-30 10:08:21] [EMAIL PROTECTED]

PHP/apache process appears to be in infinite loop 100% CPU Utilization
--

 I have the same problem , i'm using php4.0.6 and RH6.6

 Nico






Edit this bug report at http://bugs.php.net/?id=14297&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14296 Updated: Undeclared variables and isset()

2001-11-30 Thread sniper

ID: 14296
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Bogus
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
New Comment:

Not a bug.


Previous Comments:


[2001-11-30 04:36:45] [EMAIL PROTECTED]

looks like you have set error_reporting to E_ALL
while you had E_ALL & ~E_NOTICE before?

maybe by using php.ini-recommended as template
for php.ini with 4.0.6 while using php.ini-dist
for the former versions?



[2001-11-30 04:15:44] [EMAIL PROTECTED]


SYSTEM:
I use PHP 4.0.6 on Win2k pro with Apache 1.3.22 win
Loaded modules don't seem to make a difference for the described behaviour.

DESCRIPION:
Let's say we have a PHP script, the retrieves some variables via HTTP post or get. And 
the variables, passed to the script, have different names each time.
Usually we would use "isset($variable)" to check if it exists. In most cases we need 
to check the content of the variable too. So it would be nice to do that in one step.

The script of the following examples retrieved $var1 or $var or both of them via HTTP.

EXAMPLE 1:
// This would be the usual way i guess
if(isset($var1)){
  ...
}
if(isset($var2)){
  ...
}

EXAMPLE 2:
// This has been possible with PHP 3.xx - 4.0.5
// without previously checking for existence 
// of $var1/$var2
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}

EXAMPLE 3:
// With PHP 4.0.6 we would have to do this:
if(!isset($var1)){ // is NOT declared?
  $var1 = "";
}
if(!isset($var2)){ // is NOT declared?
  $var2 = "";
}
// first we had to declare them, now we can use them
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}


I wonder if this new behaviour is a bug or a feature?
Or why can't I find info about it in the changes list if it's a feature?

Please send your answer to: [EMAIL PROTECTED]

Thank you!

Volker Puttrich






Edit this bug report at http://bugs.php.net/?id=14296&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #12473 Updated: mail() sended mail is timestamped 15 hours late

2001-11-30 Thread sniper

ID: 12473
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Duplicate
Status: Closed
Bug Type: Mail related
Operating System: win2k
PHP Version: 4.0.6
New Comment:

Fixed -> closed.


Previous Comments:


[2001-11-30 04:23:04] [EMAIL PROTECTED]

Dup of #12680



[2001-07-30 18:38:47] [EMAIL PROTECTED]

mail() sended email is time stamped 15 hours back.
Like say send a email to my yahoo address, the new mail is
listed asof received yesterday.

I use php.exe to run a php script from DOS command prompt.

But when I use MS Outlook,using the same smtp server, it is OK.

Thanks,





Edit this bug report at http://bugs.php.net/?id=12473&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14295 Updated: Scope of globals has changed

2001-11-30 Thread sniper

ID: 14295
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
New Comment:

Please include short example scripts here.


Previous Comments:


[2001-11-30 03:51:40] [EMAIL PROTECTED]

The following bug or feature (not yet sure what it is ;)) is related to the scope of 
global variables.

SYSTEM:
I use PHP 4.0.6 on Win2k pro as i downloaded it from this web site. 
The loading of extra modules does not change the described behaviour.
The Server API is Apache (Apache V. 1.3.22 win)

PHP.INI:
register_globals and register_argc_argv is ON


DESCRIPTION:
I have the global variable $PHP_SELF.
Now i include a file where I want to use $PHP_SELF.
Within the included file, $PHP_SELF is unknown (it has lost it's global state), and i 
have to declare it global again.
This appears for any other global variables too, $PHP_SELF is just an example-
This behaviour seems to be new to PHP 4.0.6, because i didn't have the problem with 
4.0.5.






Edit this bug report at http://bugs.php.net/?id=14295&edit=1


-- 
PHP Development Mailing List 
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 #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread Jani Taskinen


Ask sterling about this. IMO, it's good as it is now.

--Jani


On Fri, 30 Nov 2001, Markus Fischer wrote:

>This has something ..
>
>Jani, don't you think this should be investigated ..?
>
>I thought this was made consistent or so or maybe it is
>and I just don't get the picture.
>
>- Markus
>
>On Fri, Nov 30, 2001 at 08:13:59AM -, [EMAIL PROTECTED] wrote :
>> ID: 14294
>> User updated by: [EMAIL PROTECTED]
>> Reported By: [EMAIL PROTECTED]
>> Status: Bogus
>> Bug Type: Filesystem function related
>> Operating System: FreeBSD 4.3
>> PHP Version: 4.1.0
>> New Comment:
>>
>> You don't think it's odd that the function that checks to see if a directory exists 
>returns a warning on what it's supposed to be doing??
>>
>> Earlier versions of PHP did not do this, and to me that makes it a 'bug'. While 
>yes, it can be suppressed, it should be functional in the same way previous versions 
>of PHP worked. This in no way is a 'feature' of the function.
>>
>> Previous Comments:
>> 
>>
>> [2001-11-30 02:43:04] [EMAIL PROTECTED]
>>
>> (or using @ in front of  the function)
>>
>>
>> 
>>
>> [2001-11-30 02:42:49] [EMAIL PROTECTED]
>>
>> Warnings can be supressed by setting error_reporting correctly.
>> Not a bug.
>>
>>
>> 
>>
>> [2001-11-29 21:28:20] [EMAIL PROTECTED]
>>
>> In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says 
>"stat failed on /your/path" if the path does not exist.
>>
>> This was causing havok with scripts of mine that relied on no output for errors.. 
>Of course I just suppressed the message, but it really shouldnt be there. The 
>function is designed to check for an existing dir, it should work without warnings!
>>
>> Hopefully this can be fixed in the next release.
>>
>> On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However 
>the version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work!
>>
>> Thanks guys.
>>
>> 
>>
>>
>>
>> Edit this bug report at http://bugs.php.net/?id=14294&edit=1
>>
>>
>> --
>> PHP Development Mailing List 
>> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14300 Updated: Picking up onBlur, onSubmit, OnLoad wrong

2001-11-30 Thread mfischer

ID: 14300
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: W2K
PHP Version: 4.0.6
New Comment:

Please ask support questions at [EMAIL PROTECTED]

bogus.

Previous Comments:


[2001-11-30 11:31:07] [EMAIL PROTECTED]

Basically either the php interpretor or the apache interpretor is picking up onBlur, 
OnSubmit...really anything with on_ command, when it has been encapsulated in a 
static string ie

This works:
fputs($fp,"http://www.justspeak.com/thankyou2.php\"; onS"); fputs($fp,"ubmit=\"return 
checkrequired(this)\");>");

This bombs:
fputs($fp,"http://www.justspeak.com/thankyou2.php\"; onSubmit=\"return 
checkrequired(this)\");>");

Notice how I had to split up the onSubmit 

I'm not sure whether this is an apache problem or a php java conflictsounds like 
apache to me?






Edit this bug report at http://bugs.php.net/?id=14300&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14300: Picking up onBlur, onSubmit, OnLoad wrong

2001-11-30 Thread jrfurman

From: [EMAIL PROTECTED]
Operating system: W2K
PHP version:  4.0.6
PHP Bug Type: Scripting Engine problem
Bug description:  Picking up onBlur, onSubmit, OnLoad wrong

Basically either the php interpretor or the apache interpretor is picking
up onBlur, OnSubmit...really anything with on_ command, when it has
been encapsulated in a static string ie

This works:
fputs($fp,"http://www.justspeak.com/thankyou2.php\"; onS");
fputs($fp,"ubmit=\"return checkrequired(this)\");>");

This bombs:
fputs($fp,"http://www.justspeak.com/thankyou2.php\"; onSubmit=\"return
checkrequired(this)\");>");

Notice how I had to split up the onSubmit 

I'm not sure whether this is an apache problem or a php java
conflictsounds like apache to me?

-- 
Edit bug report at: http://bugs.php.net/?id=14300&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14299: explode() case sensitivity.

2001-11-30 Thread stephen

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.6
PHP Bug Type: Documentation problem
Bug description:  explode() case sensitivity.

I recently added a note to http://www.php.net/explode and was informed that
I should probably post it here.

Original Note:
I'm not sure if this is intentional, but there is no indication whether
explode() is case insensitive. I ended up having to convert my strings and
keywords to lowercase using strtolower() in order to do this. I'm using
4.0.4, FWIW.

I don't care one way or another if this is a bug or a documentation error
since I was able to work around it, but I think other people may get
confused when it fails to explode because there's no info about case
sensitivity.

Thanks,
Stephen VanDyke
[EMAIL PROTECTED]
-- 
Edit bug report at: http://bugs.php.net/?id=14299&edit=1


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

2001-11-30 Thread Jaime Bozza

By default, garbage collection isn't being run every time a page is
loaded (both default php.ini files set session.gc_probability to 1, or
1%.) so your files are possibly sticking around for longer than 2 hours
anyway.

gc_maxlifetime only defines where or not a session is still available
and whether or not to delete the session file *when* the cleanup
happens.  If the cleanup doesn't happen (that 1% doesn't come around for
4-5 hours), then files will still be there.

I'm not really sure how the base session garbage collection defines the
"last modified/used", but I would guess they're using the mtime on the
file itself.  Introducing more checks would probably slow down gc
considerably.  Especially if your running thousands of sessions at any
given period.

Jaime Bozza


-Original Message-
From: André Næss [mailto:[EMAIL PROTECTED]] 
Sent: Friday, November 30, 2001 9:32 AM

Maybe I was unclear. The problem is that to allow for 2 hour timeouts I
need to have gc_maxlifetime set to 2 hours, but for 99,9% of all session
I don't need than 15 minutes gc_maxlifetime since they have a cookie
lifetime of 15 minutes.


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

2001-11-30 Thread Jaime Bozza

I do something like this already with my user-defined session code.  I
can see a problem with trying to build something into the default
session code and then trying to define those multiple contexts within
the php.ini file.  How many contexts?  How would you tell automatically
which context should be 2 hours and which should be 15 minutes?

When I wrote my user-defined session code, I added an "application"
field that I use within my session handler routines to define expire
time and to allow different sections of our sites to have different
data.  (I wanted to separate portions of the site, lowering the
expiration time for accounting functions and raising the expiration for
non-essential functions, etc.)

Needless to say, I think PHP session support is excellent in that it
already allows user-defined routines. Building something like this into
the base session support could make basic sessions more complicated than
they'd need to be.  

Jaime Bozza

-Original Message-
From: André Næss [mailto:[EMAIL PROTECTED]] 
Sent: Friday, November 30, 2001 9:10 AM

I find PHP session lacking in one area. In my applications I typically
want to have a long timeout for adminstrators so that they don't have to
log in all the time. A typical value is 2 hours. For users I prefer 15
minutes, based on the assumption that a user will go in, do his stuff,
and leave. For this to happen I need to have the gc_maxlifetime set to 2
hours, or risk unpredictable results for the administrators. The problem
with this is of course that garbage collection will run infrequently for
the entire system, even though most of the sessions expire after 15
minutes. It would therefore be nice to have something like "session
contexts", where you could have different session settings for each
context. Is this possible to achieve? Anyone else who can see the use of



--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: Sessions proposal

2001-11-30 Thread André Næss


"John Lim" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Hi Andre
>
> Why not simply store the login time as a session variable, and log the
> person
> out after 15 mins?
>
> Regards, John

Maybe I was unclear. The problem is that to allow for 2 hour timeouts I need
to have gc_maxlifetime set to 2 hours, but for 99,9% of all session I don't
need than 15 minutes gc_maxlifetime since they have a cookie lifetime of 15
minutes.

Also, I can't log the user out after 15 minutes (it's better to use
cookie_lifetime for that), I haven't got any idea of where he is, so storing
the login time as a session variable won't let me change the gc_maxlifetime.

André Næss


>
> André NæSs <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > I find PHP session lacking in one area. In my applications I typically
> want
> > to have a long timeout for adminstrators so that they don't have to log
in
> > all the time. A typical value is 2 hours. For users I prefer 15 minutes,
> > based on the assumption that a user will go in, do his stuff, and leave.
> For
> > this to happen I need to have the gc_maxlifetime set to 2 hours, or risk
> > unpredictable results for the administrators. The problem with this is
of
> > course that garbage collection will run infrequently for the entire
> system,
> > even though most of the sessions expire after 15 minutes. It would
> therefore
> > be nice to have something like "session contexts", where you could have
> > different session settings for each context. Is this possible to
achieve?
> > Anyone else who can see the use of this?
> >
> > Regards.
> > André Næss
> >
> >
>
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14298: PUT absent $PHP_PUT_FILENAME $PHP_UPLOADED_FILE_NAME

2001-11-30 Thread Information-Cascade

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: HTTP related
Bug description:  PUT absent $PHP_PUT_FILENAME   $PHP_UPLOADED_FILE_NAME

Document:
features.file-upload.put-method.html
SAYS:
The filename of this temporary file is in the
$PHP_PUT_FILENAME variable
SAYS:
copy(
$PHP_UPLOADED_FILE_NAME,
$DOCUMENT_ROOT.$REQUEST_URI
);

Neither works. What does?
-- 
Edit bug report at: http://bugs.php.net/?id=14298&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: Sessions proposal

2001-11-30 Thread John Lim

Hi Andre

Why not simply store the login time as a session variable, and log the
person
out after 15 mins?

Regards, John

André NæSs <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I find PHP session lacking in one area. In my applications I typically
want
> to have a long timeout for adminstrators so that they don't have to log in
> all the time. A typical value is 2 hours. For users I prefer 15 minutes,
> based on the assumption that a user will go in, do his stuff, and leave.
For
> this to happen I need to have the gc_maxlifetime set to 2 hours, or risk
> unpredictable results for the administrators. The problem with this is of
> course that garbage collection will run infrequently for the entire
system,
> even though most of the sessions expire after 15 minutes. It would
therefore
> be nice to have something like "session contexts", where you could have
> different session settings for each context. Is this possible to achieve?
> Anyone else who can see the use of this?
>
> Regards.
> André Næss
>
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: Bug #14297 Updated: CPU LOOP

2001-11-30 Thread Breuer Nicolas


 yes sure,

 it happend once / 2 hours , 2 process with 50% cpu.

 i killall with -1 httpd and all was going to normal states.

 Nico


<[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> ID: 14297
> Updated by: jmoore
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Feedback
> Bug Type: *General Issues
> Operating System: RH6.2
> PHP Version: 4.0.6
> New Comment:
>
> Is anyone here psycic cause I sure cant tell what is causing PHP to go
into 100% loop, perhaps we can have a bit more information about when it
happens and what your doing when it happens?
>
> Previous Comments:
> 
>
> [2001-11-30 10:08:21] [EMAIL PROTECTED]
>
> PHP/apache process appears to be in infinite loop 100% CPU Utilization
> --
>
>  I have the same problem , i'm using php4.0.6 and RH6.6
>
>  Nico
>
>
> 
>
>
>
> Edit this bug report at http://bugs.php.net/?id=14297&edit=1
>



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Sessions proposal

2001-11-30 Thread André Næss

I find PHP session lacking in one area. In my applications I typically want
to have a long timeout for adminstrators so that they don't have to log in
all the time. A typical value is 2 hours. For users I prefer 15 minutes,
based on the assumption that a user will go in, do his stuff, and leave. For
this to happen I need to have the gc_maxlifetime set to 2 hours, or risk
unpredictable results for the administrators. The problem with this is of
course that garbage collection will run infrequently for the entire system,
even though most of the sessions expire after 15 minutes. It would therefore
be nice to have something like "session contexts", where you could have
different session settings for each context. Is this possible to achieve?
Anyone else who can see the use of this?

Regards.
André Næss



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14297 Updated: CPU LOOP

2001-11-30 Thread jmoore

ID: 14297
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *General Issues
Operating System: RH6.2
PHP Version: 4.0.6
New Comment:

Is anyone here psycic cause I sure cant tell what is causing PHP to go into 100% loop, 
perhaps we can have a bit more information about when it happens and what your doing 
when it happens?

Previous Comments:


[2001-11-30 10:08:21] [EMAIL PROTECTED]

PHP/apache process appears to be in infinite loop 100% CPU Utilization
--

 I have the same problem , i'm using php4.0.6 and RH6.6

 Nico






Edit this bug report at http://bugs.php.net/?id=14297&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14297: CPU LOOP

2001-11-30 Thread nico

From: [EMAIL PROTECTED]
Operating system: RH6.2
PHP version:  4.0.6
PHP Bug Type: *General Issues
Bug description:  CPU LOOP

PHP/apache process appears to be in infinite loop 100% CPU Utilization
--

 I have the same problem , i'm using php4.0.6 and RH6.6

 Nico

-- 
Edit bug report at: http://bugs.php.net/?id=14297&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] mm not thread-safe

2001-11-30 Thread Holger Schopohl

Hi,

why is libmm for sessions not thread safe?

Regards,

Holger

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #12993 Updated: xpath_eval doesn't work anymore (segfault)

2001-11-30 Thread mfischer

ID: 12993
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Assigned
Bug Type: DOM XML related
Operating System: Debian/unstable Linux 2.4.9
PHP Version: 4.0CVS-2001-08-28
Old Assigned To: 
Assigned To: mfischer
New Comment:

Update: fix is comming, assigning to me.

Previous Comments:


[2001-11-21 20:11:30] [EMAIL PROTECTED]

Can you try latest RC and see if the problem still exists

http://www.php.net/~zeev/php-4.1.0RC3.tar.gz

Feedback.




[2001-08-28 04:43:24] [EMAIL PROTECTED]

mmmh...

maybe it was my fault

$node = xpath_eval($xpth,"/root/books");

seems to work, so i'm not sure if it's a bug anymore

but comparing to the other syntax, should

$node = $xpth->xpath_eval("/root/books");

not also work?







[2001-08-28 04:23:24] [EMAIL PROTECTED]

ah forgot to mention:
the script worked in 4.0.6





[2001-08-28 04:21:14] [EMAIL PROTECTED]

actually it does not work in PHP_4_0_7 from cvs as well.

script:
$fd = fopen( $datasrc, "r" );
$xmlstring = fread( $fd, filesize( $datasrc ) );
fclose( $fd );
$xml = xmldoc($xmlstring);
$xpth = $xml->xpath_new_context($xml);
$node = $xpth->xpath_eval("/root/books");

just segfaults at xpath_eval().

libxml2-version is 2.4.3

chregu





Edit this bug report at http://bugs.php.net/?id=12993&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14123 Updated: segfault (possibly dom/xml/xslt related)

2001-11-30 Thread mfischer

ID: 14123
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Assigned
Bug Type: DOM XML related
Operating System: linux redhat 7.0
PHP Version: 4.1.0RC1
Old Assigned To: 
Assigned To: mfischer
New Comment:

Update: need no example, fix is coming. Assigning to me.

Previous Comments:


[2001-11-29 09:33:48] [EMAIL PROTECTED]

Please provide a short, self-containing reproduceable script.

Feedback.



[2001-11-19 16:48:49] [EMAIL PROTECTED]

after additional research i have found it is a dom xml function bug, specifically, 
xpath_new_context().  i realize that this function is experimental, so i won't even 
make a fuss over it. :)  just letting you know.

Chris




[2001-11-19 14:51:33] [EMAIL PROTECTED]

configure options:

./configure \
--cache-file=/dev/null \
--with-config-file-path=/usr/local/apache/conf \
--with-apxs=/usr/local/apache/bin/apxs \
--enable-trans-sid \
--enable-ftp \
--enable-track-vars \
--with-mysql=/usr/local/mysql \
--enable-libgcc \
--enable-debug \
--verbose \
--with-gd=shared \
--with-dom \
--with-ttf \
--with-xml \
--with-zlib \
--with-mhash \
--prefix=/usr/local/php \
--with-regex=system \
--enable-memory-limit \
--enable-sysvsem \
--enable-sysvshm \
--with-bz2 \
--with-gettext \
--with-jpeg-dir=/usr \
--with-xpm-dir=/usr/X11R6 \
--with-ldap \
--with-mm=/usr/local/mm \
--enable-exif \
--with-pcre-regex=/usr/local/lib \
--with-expat-dir=/usr \
--without-pgsql \
--enable-shmop \
--with-snmp \
--enable-sockets \
--with-pspell \
--with-pear \
--with-iconv \
--enable-mbstring \
--enable-mbstr-enc-trans \
--enable-xslt \
--with-xslt-sablot

error_log output:

php_domxml.c(2680) :  Freeing 0x083B9F14 (12 bytes), 
script=/home/gub/public_html/SOLR2/index.php
php_domxml.c(450) :  Freeing 0x083B9ED4 (12 bytes), 
script=/home/gub/public_html/SOLR2/index.php
php_domxml.c(446) :  Freeing 0x083B9DF4 (12 bytes), 
script=/home/gub/public_html/SOLR2/index.php
php_domxml.c(480) :  Freeing 0x083B11A4 (12 bytes), 
script=/home/gub/public_html/SOLR2/index.php
zend_hash.c(176) :  Freeing 0x083B783C (32 bytes), 
script=/home/gub/public_html/SOLR2/index.php
Last leak repeated 1 time
zend_hash.c(404) :  Freeing 0x083AD3F4 (35 bytes), 
script=/home/gub/public_html/SOLR2/index.php
Last leak repeated 3 times
php_domxml.c(551) :  Freeing 0x083ABC2C (12 bytes), 
script=/home/gub/public_html/SOLR2/index.php
php_domxml.c(547) :  Freeing 0x083ABB54 (12 bytes), 
script=/home/gub/public_html/SOLR2/index.php
php_domxml.c(582) :  Freeing 0x083AA20C (12 bytes), 
script=/home/gub/public_html/SOLR2/index.php
zend_API.c(593) :  Freeing 0x083B120C (44 bytes), 
script=/home/gub/public_html/SOLR2/index.php
zend_API.c(581) : Actual location (location was relayed)
Last leak repeated 1 time

the above ALWAYS occurs, however, the segfault does NOT ALWAYS occur, i have to 
repeatedly reload the page.

backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x4032c0c7 in _zval_dtor (zvalue=0x82c77b4,
__zend_filename=0x40412abc "zend_execute_API.c", __zend_lineno=268)
at zend_variables.c:43
43  CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0  0x4032c0c7 in _zval_dtor (zvalue=0x82c77b4,
__zend_filename=0x40412abc "zend_execute_API.c", __zend_lineno=268)
at zend_variables.c:43
#1  0x40322e35 in _zval_ptr_dtor (zval_ptr=0x83880c0,
__zend_filename=0x40412431 "zend_execute.h", __zend_lineno=114)
at zend_execute_API.c:268
#2  0x40320c96 in zend_ptr_stack_clear_multiple () at zend_execute.h:114
#3  0x4031dbd7 in execute (op_array=0x8177fdc) at ./zend_execute.c:1665
#4  0x4031d8d7 in execute (op_array=0x836db94) at ./zend_execute.c:1630
#5  0x4031f8d2 in execute (op_array=0x827cadc) at ./zend_execute.c:2133
#6  0x4032dfe8 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at zend.c:814
#7  0x403401a2 in php_execute_script (primary_file=0xb5f0) at main.c:1310
#8  0x4033af5e in apache_php_module_main (r=0x81526d4, display_source_mode=0)
at sapi_apache.c:90
#9  0x4033bdd4 in send_php (r=0x81526d4, display_source_mode=0,
filename=0x81532d4 "/home/gub/public_html/SOLR2/index.php") at mod_php4.c:575
#10 0x4033be4e in send_parsed_php (r=0x81526d4) at mod_php4.c:590
#11 0x805443f in ap_invoke_handler ()
#12 0x80681d3 in process_request_internal ()
#13 0x8068234 in ap_process_request ()
#14 0x805f6d5 in child_main ()
#15 0x805f880 in make_child ()
#16 0x805f9f4 in startup_children ()
#17 0x8060043 in standalone_main ()
#18 0x806085f in main ()
#19 0x40149b5c in __libc_start_main (main=0x80604c8 , argc=2,
ubp_av=0xba54, init=0x804ea70 <_init>, fini=0x80954ac <_fini>,
rtld_fini=0x4000d634 <_dl_fini>, stack_end=0x

Re: [PHP-DEV] BC problem

2001-11-30 Thread Zeev Suraski

Yep :)

At 13:53 30/11/2001, Markus Fischer wrote:
>On Fri, Nov 30, 2001 at 01:40:54PM +0200, Zeev Suraski wrote :
> > Nope :)
>
> But you can update the NEWS file to say '4.1' and not '4.0'
> at the top X-D
>
> - Markus
>
>--
>PHP Development Mailing List 
>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] new C and PEAR extension for php (php-gmime)

2001-11-30 Thread Piotr Klaban

Hi,

I am sorry if that is not a right place to post it.
I have created new php module - php-gmime.
It is binding for C gmime library with PEAR classes:
GMIME_message, GMIME_part etc. - MIME parsing.

BUT:
I have written perl modules before, but
it is my first php extension - I am sure I have done
many mistakes. Then I need some advice - from where to start.
My module is ready for use but in BETA stage.
RPM builds and sources are available at:
  http://www.klaban.torun.pl/prog/gmime/
(page under construction).

And I have two questions for now:

1. I have seen there is some kind of packaging system
(one PEAR::Package another PECL) - is there any reliable
documentation on using it? Should I use it?

2. What name should my extension use?
The C library is called gmime (http://spruce.sourceforge.org/gmime/)
PHP module is then also called gmime.so,
and PEAR classes are called as stated above GMIME_*

My perl module is called MIME::Fast (would be
available on CPAN).

Best regards,

-- 
Piotr Klaban

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

2001-11-30 Thread James Moore

How about in future to avoid this happening when we roll the release tag as
4.1.0 or whatever call the tar.gz file php-4.1.0pre1.tar.gz then it becomes
slightly more obvious its not 4.1.0 also all we then have to do is rename
php-4.1.0pre1 to php-4.1.0.tar.gz to do the release no need to reroll where
a mistake could happen.

- James

> Nope :)
>
> At 09:19 30/11/2001, Jani Taskinen wrote:
>
> >As a minor cosmetic detail, could you set the version for
> >the 'next' release of 4.1 to be 4.1.1 ?
> >
> >Many people have downloaded the broken 'release' of 4.1.0 now
> >so we have to be able to know what version people are using
> >when they submit bug reports.
> >
> >--Jani
>
>
> --
> PHP Development Mailing List 
> 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 
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] BC problem

2001-11-30 Thread Markus Fischer

On Fri, Nov 30, 2001 at 01:40:54PM +0200, Zeev Suraski wrote : 
> Nope :)

But you can update the NEWS file to say '4.1' and not '4.0'
at the top X-D

- Markus

-- 
PHP Development Mailing List 
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] typo in Zend sources

2001-11-30 Thread Andi Gutmans

Fixed. Thanks!

Andi

At 11:16 AM 11/30/2001 +0100, Derick Rethans wrote:
>Hello,
>
>configure spits out the following line:
>checking whether dlsym() requires a leading underscode in symbol names... no
>
>this should be underscore I think...
>
>Derick
>
>
>
>--
>PHP Development Mailing List 
>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 
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] BC problem

2001-11-30 Thread Zeev Suraski

Nope :)

At 09:19 30/11/2001, Jani Taskinen wrote:

>As a minor cosmetic detail, could you set the version for
>the 'next' release of 4.1 to be 4.1.1 ?
>
>Many people have downloaded the broken 'release' of 4.1.0 now
>so we have to be able to know what version people are using
>when they submit bug reports.
>
>--Jani


-- 
PHP Development Mailing List 
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 #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread Yasuo Ohgaki

Sorry for multiple messages.
I have to be more careful when there is mail client error...

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #7782 Updated: Cannot use PATH_INFO fully with php isapi

2001-11-30 Thread derick

ID: 7782
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Bug Type: Feature/Change Request
Operating System: Windows 2000
PHP Version: 4.0.3pl1
Old Assigned To: 
Assigned To: james
New Comment:

Assigning to James (As discussed)

Previous Comments:


[2001-04-24 08:19:35] [EMAIL PROTECTED]

Hi,

Due to some problems we have had with the isapi version of php under IIS, 
we have made some changes in the sourcecode of this isapi module to support 
Apache style PATH_INFO and PATH_TRANSLATED variables. We tested it with 
IIS 5 on Windows 2000 Server.
(See also Bug number 7782).

What we have done:

- In the function "init_request_info" we have added some code which will
translate the "path_translated" server variable to a path
which points to the requested script on disk.

- In the function "sapi_isapi_register_server_variables2" we have added
some translations for the variables $PATH_INFO and $PATH_TRANSLATED
PATH_INFO will now be translated from:
/script/path/script.php/some/non/existing/path
to
/some/non/existing/path

PATH_TRANSLATED will be translated from:
d:\Inetpub\wwwroot\script.php\some\non\existing\path
to
d:\Inetpub\wwwroot\script.php

- We have added a function named "sapi_isapi_get_server_var"
which will retrieve the requested server variable and returns
a pointer to it. This function has been added to make things more
structured (because of the need to check for a "INSUFFICIENT BUFFER"
error).

We have made a patch file of these changes against the cvs version 1.7 of 
php4isapi.c. This path file is attached to this e-mail.

Please keep in mind that we did not have the opportunity to test this fix with Zeus.

We hope you can/will commit this fix to the php cvs repository.

With kind regards,

Gijsbert te Riet,
Muze.
[EMAIL PROTECTED]

patch:
16a17
>| IIS PATH_TRANSLATED / PATH_INFO fix: Gijsbert te Riet <[EMAIL PROTECTED]> |
83a85
>   "PATH_INFO",
88a91
>   "REQUEST_URI",
464a468,492
> static char *sapi_isapi_get_server_var(LPEXTENSION_CONTROL_BLOCK lpECB, char 
>*varname, DWORD *buffer_len) {
>   char*buffer;
> 
>   buffer=emalloc(*buffer_len=ISAPI_SERVER_VAR_BUF_SIZE);
>   if (!lpECB->GetServerVariable(lpECB->ConnID, varname, buffer, buffer_len)) {
>   if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
> 
>   buffer = (char *) erealloc(buffer, *buffer_len);
>   if (!lpECB->GetServerVariable(lpECB->ConnID, varname, buffer, 
>buffer_len)) {
> 
>   efree(buffer);
>   buffer=0;
> 
>   }
> 
>   } else {
> 
>   efree(buffer);
>   buffer=0;
>   }
>   }
> 
>   return buffer;
> }
> 
468,469c496
<   DWORD variable_len;
<   char static_variable_buf[ISAPI_SERVER_VAR_BUF_SIZE];
---
>   DWORD varsize, varbufsize; 
470a498
>   char *var_buf1, *var_buf2;
473,478c501,508
<   variable_len = ISAPI_SERVER_VAR_BUF_SIZE;
<   if (lpECB->GetServerVariable(lpECB->ConnID, *p, static_variable_buf, 
&variable_len)
<   && static_variable_buf[0]) {
<   php_register_variable(*p, static_variable_buf, 
track_vars_array ELS_CC PLS_CC);
<   if (recorded_values) {
<   recorded_values[p-server_variables] = 
estrndup(static_variable_buf, variable_len);
---
> 
>   if (variable_buf=sapi_isapi_get_server_var(lpECB, *p, &varsize)) {
>   // translate PATH_INFO to Apache compatible PATH_INFO
>   if (strcmp(*p, "PATH_INFO") == 0) {
>   if (var_buf1=sapi_isapi_get_server_var(lpECB, 
>"SCRIPT_NAME", &varbufsize)) {
>   memmove(variable_buf, variable_buf + 
>strlen(var_buf1), strlen(variable_buf) - strlen(var_buf1) + 1);
>   efree(var_buf1);
>   }
480,484c510,519
<   } else if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
<   variable_buf = (char *) emalloc(variable_len);
<   if (lpECB->GetServerVariable(lpECB->ConnID, *p, variable_buf, 
&variable_len)
<   && variable_buf[0]) {
<   php_register_variable(*p, variable_buf, 
track_vars_array ELS_CC PLS_CC);
---
> 
>   // translate PATH_TRANSLATED to Apache compatible 
>PATH_TRANSLATED 
>   if (strcmp(*p, "PATH_TRANSLATED") == 0) {
>   if (

[PHP-DEV] Additional argument to exec family

2001-11-30 Thread Andrey Hristov

I've spent 2 hour to find where is the problem and evetually I found that I had to 
redirect the std_err stream to std_out to view
why a command executed by exec() breaks(to view the error). Is it possible someone to 
add 2 aditional parameters to exec() so in
case the error_code which is returned and !=0 to read from std_err and pass all data 
to the second additional parameterstring exec
(string command, string  [array] [, int return_var,[ bool use_std_err, string [array] 
std_err_output ]);

Regards

Andrey Hristov


-- 
PHP Development Mailing List 
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: PATH_INFO doesn't work -- resolution?

2001-11-30 Thread Gijsbert te Riet

Hi Derick,

>
> can you resend that patch to php-dev?


Ofcourse. The patch against the php-4.0.6 php4isapi.c is attached.
If you would like to have a patch against the current CVS version then
please let me know so i can make time to test it first.

Please note that we weren't able to test this fix with other webservers
than IIS.

Regards,
Gijsbert te Riet.
Muze.



--- php4isapi.c Fri Nov 30 12:33:52 2001
+++ isapi.fix   Fri Nov 30 12:35:29 2001
@@ -17,6 +17,7 @@
+--+
  */
 
+
 #ifdef PHP_WIN32
 # include 
 # include 
@@ -81,11 +82,13 @@
"CONTENT_LENGTH",
"CONTENT_TYPE",
"PATH_TRANSLATED",
+   "PATH_INFO",
"QUERY_STRING",
"REMOTE_ADDR",
"REMOTE_HOST",
"REMOTE_USER",
"REQUEST_METHOD",
+   "REQUEST_URI",
"SERVER_NAME",
"SERVER_PORT",
"SERVER_PROTOCOL",
@@ -462,38 +465,73 @@
 #endif
 
 
+static char *sapi_isapi_get_server_var(LPEXTENSION_CONTROL_BLOCK lpECB, char 
+*varname, DWORD *buffer_len) {
+   char*buffer;
+
+   buffer=emalloc(*buffer_len=ISAPI_SERVER_VAR_BUF_SIZE);
+   if (!lpECB->GetServerVariable(lpECB->ConnID, varname, buffer, buffer_len)) {
+   if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
+
+   buffer = (char *) erealloc(buffer, *buffer_len);
+   if (!lpECB->GetServerVariable(lpECB->ConnID, varname, buffer, 
+buffer_len)) {
+
+   efree(buffer);
+   buffer=0;
+
+   }
+
+   } else {
+
+   efree(buffer);
+   buffer=0;
+   }
+   }
+
+   return buffer;
+}
+
 static void sapi_isapi_register_server_variables2(char **server_variables, 
LPEXTENSION_CONTROL_BLOCK lpECB, zval *track_vars_array, char **recorded_values ELS_DC 
PLS_DC)
 {
char **p=server_variables;
-   DWORD variable_len;
-   char static_variable_buf[ISAPI_SERVER_VAR_BUF_SIZE];
+   DWORD varsize, varbufsize; 
char *variable_buf;
+   char *var_buf1, *var_buf2;
 
while (*p) {
-   variable_len = ISAPI_SERVER_VAR_BUF_SIZE;
-   if (lpECB->GetServerVariable(lpECB->ConnID, *p, static_variable_buf, 
&variable_len)
-   && static_variable_buf[0]) {
-   php_register_variable(*p, static_variable_buf, 
track_vars_array ELS_CC PLS_CC);
-   if (recorded_values) {
-   recorded_values[p-server_variables] = 
estrndup(static_variable_buf, variable_len);
+
+   if (variable_buf=sapi_isapi_get_server_var(lpECB, *p, &varsize)) {
+   // translate PATH_INFO to Apache compatible PATH_INFO
+   if (strcmp(*p, "PATH_INFO") == 0) {
+   if (var_buf1=sapi_isapi_get_server_var(lpECB, 
+"SCRIPT_NAME", &varbufsize)) {
+   memmove(variable_buf, variable_buf + 
+strlen(var_buf1), strlen(variable_buf) - strlen(var_buf1) + 1);
+   efree(var_buf1);
+   }
}
-   } else if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) {
-   variable_buf = (char *) emalloc(variable_len);
-   if (lpECB->GetServerVariable(lpECB->ConnID, *p, variable_buf, 
&variable_len)
-   && variable_buf[0]) {
-   php_register_variable(*p, variable_buf, 
track_vars_array ELS_CC PLS_CC);
+
+   // translate PATH_TRANSLATED to Apache compatible 
+PATH_TRANSLATED 
+   if (strcmp(*p, "PATH_TRANSLATED") == 0) {
+   if (var_buf1=sapi_isapi_get_server_var(lpECB, 
+"PATH_INFO", &varbufsize)) {
+   if (var_buf2=sapi_isapi_get_server_var(lpECB, 
+"SCRIPT_NAME", &varbufsize)) {
+   
+variable_buf[strlen(variable_buf)-(strlen(var_buf1)-strlen(var_buf2))]='\0';
+   efree(var_buf2);
+   }
+   efree(var_buf1);
+   }
}
+
+   php_register_variable(*p, variable_buf, track_vars_array 
+ELS_CC PLS_CC);
if (recorded_values) {
-   recorded_values[p-server_variables] = variable_buf;
-   } else {
-   efree(variable_buf);
+   recorded_values[p-server_variables] = 
+estrndup(variable_buf, varsize);
}
+
+   ef

Re: [PHP-DEV] Re: PATH_INFO doesn't work -- resolution?

2001-11-30 Thread derick

Hello Gijsbert,

can you resend that patch to php-dev?

Derick

On Fri, 30 Nov 2001, Gijsbert te Riet wrote:

> Hi Albert James,
>
> 
>
> > PROBLEM:
> > PHP seems to support this functionality on a UNIX server I run.  A request
> > for http://www.foobar.com/hello.php/more/foobar/filename.html works
> > exactly as the above describes, stuffing "/more/foobar/filename.html" into
> > the $PATH_INFO php variable.
> >
> > However, the problem is that when the same code is moved to a production
> > server, it fails with a status code 500.  A request for hello.php works
> > fine; a request for hello.php/ fails, as does hello.php/anything.  I am
> > trying to find out if the prod. server is in fact Windows.  We have a
> > workaround whereby we make the php a perl cgi and it works fine; i.e.
> > hello.cgi/anything runs fine, hello.php/anything yields a 500.
> >
> > HELP!
> > Can someone who is familiar with this component of PHP please let us know
> > if there are any specific configuratoin parameters that would affect the
> > way PHP resolves the target resource, or if this is a bug that was fixed
> > in a certain release?  I did search and found many similar problems but no
> > answers.  There is one relative post in the faqts, but it states PATH_INFO
> > doesn't work on Windows, which is clearly not true per above CGI
> > workaround.
> >
>
>
> We have also filed such an error report (back in April this year, bug id
> #7782). This is the same problem you have. It's due to IIS which
> doesn't really translate the PATH_TRANSLATED variable (it will pass php
> the actual script location + the extra PATH_INFO, so PHP cannot find the
> requested script on disk). We have made several patches to the
> php4isapi.dll to let PHP translate the request itself so it _can_ load
> the actual script with the correct PATH_INFO. This patch has been send to
> the PHP_DEV list (by the BUG-FORM) and a newer patch has been send to the
> maintainer of the php4isapi.dll, but for now they haven't been added to
> the php cvs.
>
> However, you can download the patched php4isapi.c file (for the php-4.0.6
> release) and the compiled
> version (php4isapi.dll for php-4.0.6) from
> ftp://ftp.muze.nl/pub/ariadne/win/iis/php-4.0.6/.
>
> Regards,
> Gijsbert te Riet
> Muze.
>
>
>
>
>
>
> --
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: PATH_INFO doesn't work -- resolution?

2001-11-30 Thread Gijsbert te Riet

Hi Albert James,



> PROBLEM:
> PHP seems to support this functionality on a UNIX server I run.  A request
> for http://www.foobar.com/hello.php/more/foobar/filename.html works
> exactly as the above describes, stuffing "/more/foobar/filename.html" into
> the $PATH_INFO php variable.
>
> However, the problem is that when the same code is moved to a production
> server, it fails with a status code 500.  A request for hello.php works
> fine; a request for hello.php/ fails, as does hello.php/anything.  I am
> trying to find out if the prod. server is in fact Windows.  We have a
> workaround whereby we make the php a perl cgi and it works fine; i.e.
> hello.cgi/anything runs fine, hello.php/anything yields a 500.
>
> HELP!
> Can someone who is familiar with this component of PHP please let us know
> if there are any specific configuratoin parameters that would affect the
> way PHP resolves the target resource, or if this is a bug that was fixed
> in a certain release?  I did search and found many similar problems but no
> answers.  There is one relative post in the faqts, but it states PATH_INFO
> doesn't work on Windows, which is clearly not true per above CGI
> workaround.
>


We have also filed such an error report (back in April this year, bug id
#7782). This is the same problem you have. It's due to IIS which
doesn't really translate the PATH_TRANSLATED variable (it will pass php
the actual script location + the extra PATH_INFO, so PHP cannot find the
requested script on disk). We have made several patches to the
php4isapi.dll to let PHP translate the request itself so it _can_ load
the actual script with the correct PATH_INFO. This patch has been send to
the PHP_DEV list (by the BUG-FORM) and a newer patch has been send to the
maintainer of the php4isapi.dll, but for now they haven't been added to
the php cvs.

However, you can download the patched php4isapi.c file (for the php-4.0.6
release) and the compiled
version (php4isapi.dll for php-4.0.6) from
ftp://ftp.muze.nl/pub/ariadne/win/iis/php-4.0.6/.

Regards,
Gijsbert te Riet
Muze.






-- 
PHP Development Mailing List 
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 #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread Yasuo Ohgaki

Markus Fischer wrote:

> This has something ..
> 
> Jani, don't you think this should be investigated ..?
> 
> I thought this was made consistent or so or maybe it is
> and I just don't get the picture.
>

> - Markus


I don't remember which modules was it, but I saw commit getting 
rid of warnings.

I think we really need consistency for error messages... at least 
for standard module functions.

--
Yasuo Ohgaki

> 
> On Fri, Nov 30, 2001 at 08:13:59AM -, [EMAIL PROTECTED] wrote : 
> 
>>ID: 14294
>>User updated by: [EMAIL PROTECTED]
>>Reported By: [EMAIL PROTECTED]
>>Status: Bogus
>>Bug Type: Filesystem function related
>>Operating System: FreeBSD 4.3
>>PHP Version: 4.1.0
>>New Comment:
>>
>>You don't think it's odd that the function that checks to see if a directory exists 
>returns a warning on what it's supposed to be doing??
>>
>>Earlier versions of PHP did not do this, and to me that makes it a 'bug'. While yes, 
>it can be suppressed, it should be functional in the same way previous versions of 
>PHP worked. This in no way is a 'feature' of the function.
>>
>>Previous Comments:
>>
>>
>>[2001-11-30 02:43:04] [EMAIL PROTECTED]
>>
>>(or using @ in front of  the function)
>>
>>
>>
>>
>>[2001-11-30 02:42:49] [EMAIL PROTECTED]
>>
>>Warnings can be supressed by setting error_reporting correctly.
>>Not a bug.
>>
>>
>>
>>
>>[2001-11-29 21:28:20] [EMAIL PROTECTED]
>>
>>In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says 
>"stat failed on /your/path" if the path does not exist.
>>
>>This was causing havok with scripts of mine that relied on no output for errors.. Of 
>course I just suppressed the message, but it really shouldnt be there. The function 
>is designed to check for an existing dir, it should work without warnings!
>>
>>Hopefully this can be fixed in the next release.
>>
>>On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However 
>the version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work!
>>
>>Thanks guys.
>>
>>
>>
>>
>>
>>Edit this bug report at http://bugs.php.net/?id=14294&edit=1
>>
>>
>>-- 
>>PHP Development Mailing List 
>>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 
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 #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread Yasuo Ohgaki

Markus Fischer wrote:

> This has something ..
> 
> Jani, don't you think this should be investigated ..?
> 
> I thought this was made consistent or so or maybe it is
> and I just don't get the picture.
>

> - Markus


I don't remember which modules was it, but I saw commit getting 
rid of warnings.

I think we really need consistency for error messages...

--
Yasuo Ohgaki

> 
> On Fri, Nov 30, 2001 at 08:13:59AM -, [EMAIL PROTECTED] wrote : 
> 
>>ID: 14294
>>User updated by: [EMAIL PROTECTED]
>>Reported By: [EMAIL PROTECTED]
>>Status: Bogus
>>Bug Type: Filesystem function related
>>Operating System: FreeBSD 4.3
>>PHP Version: 4.1.0
>>New Comment:
>>
>>You don't think it's odd that the function that checks to see if a directory exists 
>returns a warning on what it's supposed to be doing??
>>
>>Earlier versions of PHP did not do this, and to me that makes it a 'bug'. While yes, 
>it can be suppressed, it should be functional in the same way previous versions of 
>PHP worked. This in no way is a 'feature' of the function.
>>
>>Previous Comments:
>>
>>
>>[2001-11-30 02:43:04] [EMAIL PROTECTED]
>>
>>(or using @ in front of  the function)
>>
>>
>>
>>
>>[2001-11-30 02:42:49] [EMAIL PROTECTED]
>>
>>Warnings can be supressed by setting error_reporting correctly.
>>Not a bug.
>>
>>
>>
>>
>>[2001-11-29 21:28:20] [EMAIL PROTECTED]
>>
>>In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says 
>"stat failed on /your/path" if the path does not exist.
>>
>>This was causing havok with scripts of mine that relied on no output for errors.. Of 
>course I just suppressed the message, but it really shouldnt be there. The function 
>is designed to check for an existing dir, it should work without warnings!
>>
>>Hopefully this can be fixed in the next release.
>>
>>On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However 
>the version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work!
>>
>>Thanks guys.
>>
>>
>>
>>
>>
>>Edit this bug report at http://bugs.php.net/?id=14294&edit=1
>>
>>
>>-- 
>>PHP Development Mailing List 
>>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Should functions raise warning or not?

2001-11-30 Thread Yasuo Ohgaki
File system functions fopen(), stat(), is_dir(), is_file(), etc
are designed to raise warnings for non-existing file/path for
histrical reason(?) There are many functions behave this way.

Is there good reason for warning? Even if functions return false
for errors?

If "false" indicate error, returning "false" is enough. Scripts
should handle "false" anyway. Therefore, if the behavior is
changed, impact for existing scripts is minimum.

I put @ before functions like fopen(), is_dir() and I always feel
this isn't the way should be.

It may be better to have clear guideline for error messages for
both script coders and module developers.

--
Yasuo Ohgaki

[EMAIL PROTECTED] wrote:

> ID: 14294
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Status: Bogus
> Bug Type: Filesystem function related
> Operating System: FreeBSD 4.3
> PHP Version: 4.1.0
> New Comment:
> 
> (or using @ in front of  the function)
> 
> 
> Previous Comments:
> 
> 
> [2001-11-30 02:42:49] [EMAIL PROTECTED]
> 
> Warnings can be supressed by setting error_reporting correctly.
> Not a bug.
> 
> 
> 
> 
> [2001-11-29 21:28:20] [EMAIL PROTECTED]
> 
> In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says 
>"stat failed on /your/path" if the path does not exist.
> 
> This was causing havok with scripts of mine that relied on no output for errors.. Of 
>course I just suppressed the message, but it really shouldnt be there. The function 
>is designed to check for an existing dir, it should work without warnings!
> 
> Hopefully this can be fixed in the next release.
> 
> On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However 
>the version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work!
> 
> Thanks guys.
> 
> 
> 
> 
> 
> Edit this bug report at http://bugs.php.net/?id=14294&edit=1
> 
> 




_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

2001-11-30 Thread Marc Boeren


> > since news about 4.1.0 leaked out to the php-general list, 
> > wouldn't it make sense to call this one 4.1.1? (or 4.1.0pl1? :)

+1 on 4.1.1

> Why?? Yes 4.1.0 was leaked on php-general and php-homepage.de 
> but both were replied to making it very clear 4.1.0 hasnt been
> released yet. calling 4.1.0pl1 or 4.1.1 will be even more confusing
> as a lot of people will ask what happened to 4.1.0

You are assuming other people read the replies then, instead of rushing off
and getting the latest version of php :). Since there was, although for a
very short time, a 4.1.0 available (even though unofficial), it makes sense
to name the upcoming release 4.1.1.
A single line of explanation on the download page or in reply to questions
could easily explain things to people, whereas it is much more difficult to
respond to bug-reports with the question 'did you use the unofficial or the
official 4.1.0?' and all the hassle that will follow...

Cheerio, Marc.

-- 
PHP Development Mailing List 
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-QA] PHP 4.1.0RC4

2001-11-30 Thread James Moore




> since news about 4.1.0 leaked out to the php-general list, wouldn't it
> make sense to call this one 4.1.1? (or 4.1.0pl1? :)
>

Why?? Yes 4.1.0 was leaked on php-general and php-homepage.de but both were
replied to making it very clear 4.1.0 hasnt been released yet. calling
4.1.0pl1 or 4.1.1 will be even more confusing as a lot of people will ask
what happened to 4.1.0

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] typo in Zend sources

2001-11-30 Thread Derick Rethans

Hello,

configure spits out the following line:
checking whether dlsym() requires a leading underscode in symbol names... no

this should be underscore I think...

Derick



-- 
PHP Development Mailing List 
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 #14296 Updated: Undeclared variables and isset()

2001-11-30 Thread Philip Olson

E_NOTICE:
http://www.php.net/manual/en/phpdevel-errors.php#internal.e-notice
http://www.php.net/manual/en/configuration.php#ini.error-reporting

The following won't create a E_NOTICE level error when $var is not set:

  if (isset($var) && $var == 'foo') {
echo 'I Love to foo';
  }

Could also use a @ but it's not as cool imho :)

  if (@$var == 'foo') {
echo 'I love to foo';
  }

So as suggested, this depends on your particular settings.  Also see the
error_reporting() function.

regards,
Philip Olson


On 30 Nov 2001 [EMAIL PROTECTED] wrote:

> ID: 14296
> Updated by: hholzgra
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Feedback
> Bug Type: Variables related
> Operating System: Win2k
> PHP Version: 4.0.6
> New Comment:
> 
> looks like you have set error_reporting to E_ALL
> while you had E_ALL & ~E_NOTICE before?
> 
> maybe by using php.ini-recommended as template
> for php.ini with 4.0.6 while using php.ini-dist
> for the former versions?
> 
> Previous Comments:
> 
> 
> [2001-11-30 04:15:44] [EMAIL PROTECTED]
> 
> 
> SYSTEM:
> I use PHP 4.0.6 on Win2k pro with Apache 1.3.22 win
> Loaded modules don't seem to make a difference for the described behaviour.
> 
> DESCRIPION:
> Let's say we have a PHP script, the retrieves some variables via HTTP post or get. 
>And the variables, passed to the script, have different names each time.
> Usually we would use "isset($variable)" to check if it exists. In most cases we need 
>to check the content of the variable too. So it would be nice to do that in one step.
> 
> The script of the following examples retrieved $var1 or $var or both of them via 
>HTTP.
> 
> EXAMPLE 1:
> // This would be the usual way i guess
> if(isset($var1)){
>   ...
> }
> if(isset($var2)){
>   ...
> }
> 
> EXAMPLE 2:
> // This has been possible with PHP 3.xx - 4.0.5
> // without previously checking for existence 
> // of $var1/$var2
> if($var1 == "something"){
>   ...
> }
> if($var2 == "anything"){
>   ...
> }
> 
> EXAMPLE 3:
> // With PHP 4.0.6 we would have to do this:
> if(!isset($var1)){ // is NOT declared?
>   $var1 = "";
> }
> if(!isset($var2)){ // is NOT declared?
>   $var2 = "";
> }
> // first we had to declare them, now we can use them
> if($var1 == "something"){
>   ...
> }
> if($var2 == "anything"){
>   ...
> }
> 
> 
> I wonder if this new behaviour is a bug or a feature?
> Or why can't I find info about it in the changes list if it's a feature?
> 
> Please send your answer to: [EMAIL PROTECTED]
> 
> Thank you!
> 
> Volker Puttrich
> 
> 
> 
> 
> 
> 
> Edit this bug report at http://bugs.php.net/?id=14296&edit=1
> 
> 
> -- 
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14296 Updated: Undeclared variables and isset()

2001-11-30 Thread hholzgra

ID: 14296
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Variables related
Operating System: Win2k
PHP Version: 4.0.6
New Comment:

looks like you have set error_reporting to E_ALL
while you had E_ALL & ~E_NOTICE before?

maybe by using php.ini-recommended as template
for php.ini with 4.0.6 while using php.ini-dist
for the former versions?

Previous Comments:


[2001-11-30 04:15:44] [EMAIL PROTECTED]


SYSTEM:
I use PHP 4.0.6 on Win2k pro with Apache 1.3.22 win
Loaded modules don't seem to make a difference for the described behaviour.

DESCRIPION:
Let's say we have a PHP script, the retrieves some variables via HTTP post or get. And 
the variables, passed to the script, have different names each time.
Usually we would use "isset($variable)" to check if it exists. In most cases we need 
to check the content of the variable too. So it would be nice to do that in one step.

The script of the following examples retrieved $var1 or $var or both of them via HTTP.

EXAMPLE 1:
// This would be the usual way i guess
if(isset($var1)){
  ...
}
if(isset($var2)){
  ...
}

EXAMPLE 2:
// This has been possible with PHP 3.xx - 4.0.5
// without previously checking for existence 
// of $var1/$var2
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}

EXAMPLE 3:
// With PHP 4.0.6 we would have to do this:
if(!isset($var1)){ // is NOT declared?
  $var1 = "";
}
if(!isset($var2)){ // is NOT declared?
  $var2 = "";
}
// first we had to declare them, now we can use them
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}


I wonder if this new behaviour is a bug or a feature?
Or why can't I find info about it in the changes list if it's a feature?

Please send your answer to: [EMAIL PROTECTED]

Thank you!

Volker Puttrich






Edit this bug report at http://bugs.php.net/?id=14296&edit=1


-- 
PHP Development Mailing List 
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-QA] PHP 4.1.0RC4

2001-11-30 Thread Derick Rethans

On Fri, 30 Nov 2001, Hartmut Holzgraefe wrote:

> yes, lets follow the apache scheme of skiping version numbers for
> versions that might have slipped out ahead of time, even if not as
> obvious as in this case, just to make sure to prevent any chance of
> confusion, as we have nothing to loose by starting the 4.1 series
> with a 4.1.1 and one additional sentence in the announcement

I agree with this, to make sure there is no confusion about which version
is used (when submitting bugs per example).

Derick


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #12680 Updated: mail() is sent with incorrect timezone

2001-11-30 Thread derick

ID: 12680
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Mail related
Operating System: Windows NT 4.0 SP6
PHP Version: 4.0.6
New Comment:

Fixed in CVS

Previous Comments:


[2001-08-10 11:01:14] [EMAIL PROTECTED]

This happens with just PHP.  As I said, I can directly connect to port 25 and manually 
enter SMTP commands to send an email (see second mail header sample).  The timezone 
correctly shows -0500 for CDT.  The time listed in the PHP-created email shows the 
time correctly, but doesn't show the timezone correctly (see first mail header sample).



[2001-08-10 10:45:12] [EMAIL PROTECTED]

something similar has been reported as a bug in 4.0 and was
assigned to hholzgra.  I don't know if it has been fixed.

Suspended until I can contact him and see if he's fixed it.

If anybody else knows anything about this, second opinion is
welcome.



[2001-08-10 10:36:59] [EMAIL PROTECTED]

This happens with just PHP.  As I said, I can directly connect to port 25 and manually 
enter SMTP commands to send an email (see second mail header sample).  The timezone 
correctly shows -0500 for CDT.  The time listed in the PHP-created email shows the 
time correctly, but doesn't show the timezone correctly (see first mail header sample).



[2001-08-10 10:32:55] [EMAIL PROTECTED]

Does this happen with just PHP, or with any mail program
that you use?



[2001-08-10 10:26:31] [EMAIL PROTECTED]

Yes, the timezone and time have been verified on the server and on my workstation.  
Both are set to CDT (-0500).

The test email reflected the correct timezone, but the PHP-created one did not.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=12680


Edit this bug report at http://bugs.php.net/?id=12680&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #8909 Updated: PHP generates the Date: header line with a bad timezone

2001-11-30 Thread derick

ID: 8909
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: Mail related
Operating System: Windows
PHP Version: 4.0.4pl1
Old Assigned To: hholzgra
Assigned To: 
New Comment:

This is now fixed in CVS (I hope).

Derick

Previous Comments:


[2001-06-22 18:28:32] [EMAIL PROTECTED]

windows mailcode needs a rewrite



[2001-01-25 11:54:32] [EMAIL PROTECTED]

If the PHP mail() function is allowed to generate the "Date:" header field, the sign 
of the timezone is inverted.

The system "timezone" is the number of minutes difference between UTC and local time 
(EST= +300).  In the Date: header, the timezone is formatted as "HHMM" and is the 
difference between local time and UTC (reversed difference, EST= -0500).

In win32/sendmail.c, the sign of the system "timezone" variable is copied to the Date: 
header without being inverted.

Also, there should be a sign even if the timezone offset is 0.  Therefore in sprintf() 
that generates the "Date:" header in the PostHeader() function, the timezone test 
should read:
  (_timezone > 0) ? "-" : "+",

This problem was also in the PHP3 source.

Regard, -Ron-





Edit this bug report at http://bugs.php.net/?id=8909&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #12178 Updated: ext/standard/mail.c insecurity

2001-11-30 Thread derick

ID: 12178
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Mail related
Operating System: All UNIX
PHP Version: 4.0.6
New Comment:

This was fixed a long time ago. (on 2001/07/05 08:47:37)



Previous Comments:


[2001-07-15 13:14:46] [EMAIL PROTECTED]

ext/standard/mail.c is potentialy insecure.

>extra_cmd = (*argv[4])->value.str.val;
>strcat (sendmail_cmd, extra_cmd);
>sendmail = popen(sendmail_cmd, "w");

So it is possible to use extra_cmd to gain shell access.





Edit this bug report at http://bugs.php.net/?id=12178&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #12473 Updated: mail() sended mail is timestamped 15 hours late

2001-11-30 Thread derick

ID: 12473
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Duplicate
Bug Type: Mail related
Operating System: win2k
PHP Version: 4.0.6
New Comment:

Dup of #12680

Previous Comments:


[2001-07-30 18:38:47] [EMAIL PROTECTED]

mail() sended email is time stamped 15 hours back.
Like say send a email to my yahoo address, the new mail is
listed asof received yesterday.

I use php.exe to run a php script from DOS command prompt.

But when I use MS Outlook,using the same smtp server, it is OK.

Thanks,





Edit this bug report at http://bugs.php.net/?id=12473&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] assertion

2001-11-30 Thread Harald Radi

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 
- - -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

hi,

i always get an assertion at line 122 in zend_opcode.c on module shutdown under win32, 
but it works under linux.
i totally don't understand this as line 122 is 'free(ce->name);' and name gets 
malloc()'ed and memcpy()'ed in
zend_register_internal_class().

what did i wrong ?

harald

ps.: compiling against latest 4.2.0-dev

- - -BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBPAcwhK1+myS9SSHxEQKaawCgxVc6Gm3Nt5BNz5YFv1szDUylqC0An3Lc
fjq/dzbqBn7AUoz1ngI542OO
=QkTP
- - -END PGP SIGNATURE-
 
- -BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBPAcwvK1+myS9SSHxEQJ9ygCfYj8ru1YjYoGg5bkIkxddp8ww3L8An0XQ
3URW5zJrEdNTg/5n0vwAssam
=eEjl
- -END PGP SIGNATURE-
 
-BEGIN PGP SIGNATURE-
Version: PGP 7.0.4

iQA/AwUBPAdHNK1+myS9SSHxEQLw/ACfdNT1RvEVZqjvuG8sQj5eCmsfX2EAn0kS
Qop7aaw3AbkuUT7oDcudmIyZ
=h6xp
-END PGP SIGNATURE-
 


sviparser.zip
Description: Zip compressed data

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


[PHP-DEV] Bug #14296: Undeclared variables and isset()

2001-11-30 Thread v . puttrich

From: [EMAIL PROTECTED]
Operating system: Win2k
PHP version:  4.0.6
PHP Bug Type: Variables related
Bug description:  Undeclared variables and isset()


SYSTEM:
I use PHP 4.0.6 on Win2k pro with Apache 1.3.22 win
Loaded modules don't seem to make a difference for the described
behaviour.

DESCRIPION:
Let's say we have a PHP script, the retrieves some variables via HTTP post
or get. And the variables, passed to the script, have different names each
time.
Usually we would use "isset($variable)" to check if it exists. In most
cases we need to check the content of the variable too. So it would be nice
to do that in one step.

The script of the following examples retrieved $var1 or $var or both of
them via HTTP.

EXAMPLE 1:
// This would be the usual way i guess
if(isset($var1)){
  ...
}
if(isset($var2)){
  ...
}

EXAMPLE 2:
// This has been possible with PHP 3.xx - 4.0.5
// without previously checking for existence 
// of $var1/$var2
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}

EXAMPLE 3:
// With PHP 4.0.6 we would have to do this:
if(!isset($var1)){ // is NOT declared?
  $var1 = "";
}
if(!isset($var2)){ // is NOT declared?
  $var2 = "";
}
// first we had to declare them, now we can use them
if($var1 == "something"){
  ...
}
if($var2 == "anything"){
  ...
}


I wonder if this new behaviour is a bug or a feature?
Or why can't I find info about it in the changes list if it's a feature?

Please send your answer to: [EMAIL PROTECTED]

Thank you!

Volker Puttrich

-- 
Edit bug report at: http://bugs.php.net/?id=14296&edit=1


-- 
PHP Development Mailing List 
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-QA] PHP 4.1.0RC4

2001-11-30 Thread Hartmut Holzgraefe

Tobias Schenck wrote:

> actually not just news leaked out:
> 
> I found a download-link on one of the german php-related sites and
> downloaded php-4.1.0.tar.gz (around 27th 9:43 GMT).
> Short time after the announcement just disappeared. I don't know about the
> traffic on php-center.de or phpwelt.de (was on one of the sites) but quite a
> couple of people not tracking php.dev might have downloaded it.
> 
> From the sight of marketing I would favor 4.1.1 but I'm neither a developer
> nor on the QA-team.

yes, lets follow the apache scheme of skiping version numbers for
versions that might have slipped out ahead of time, even if not as
obvious as in this case, just to make sure to prevent any chance of
confusion, as we have nothing to loose by starting the 4.1 series
with a 4.1.1 and one additional sentence in the announcement

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




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #14295: Scope of globals has changed

2001-11-30 Thread v . puttrich

From: [EMAIL PROTECTED]
Operating system: Win2k
PHP version:  4.0.6
PHP Bug Type: Variables related
Bug description:  Scope of globals has changed

The following bug or feature (not yet sure what it is ;)) is related to the
scope of global variables.

SYSTEM:
I use PHP 4.0.6 on Win2k pro as i downloaded it from this web site. 
The loading of extra modules does not change the described behaviour.
The Server API is Apache (Apache V. 1.3.22 win)

PHP.INI:
register_globals and register_argc_argv is ON


DESCRIPTION:
I have the global variable $PHP_SELF.
Now i include a file where I want to use $PHP_SELF.
Within the included file, $PHP_SELF is unknown (it has lost it's global
state), and i have to declare it global again.
This appears for any other global variables too, $PHP_SELF is just an
example-
This behaviour seems to be new to PHP 4.0.6, because i didn't have the
problem with 4.0.5.

-- 
Edit bug report at: http://bugs.php.net/?id=14295&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #13364 Updated: Add support for ATTLIST

2001-11-30 Thread mfischer

ID: 13364
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Old Bug Type: Feature/Change Request
Bug Type: DOM XML related
Operating System: Debian x86 unstable
PHP Version: 4.0.6
Assigned To: mfischer
New Comment:

Stupid me, leave this domxml related.

Previous Comments:


[2001-11-30 03:34:44] [EMAIL PROTECTED]

Fix for crash is coming, but yet this is a feature request to support ATTLIST.

Assigned to me.



[2001-09-18 08:47:01] [EMAIL PROTECTED]

Program received signal SIGSEGV, Segmentation fault.
node_list_wrapper_dtor (node=0x82f5b80) at php_domxml.c:315
warning: Source file is more recent than executable.

315 if (!node || node->type == XML_DTD_NODE)
(gdb) bt
#0  node_list_wrapper_dtor (node=0x82f5b80) at php_domxml.c:315
#1  0x809ce58 in php_free_xml_doc (rsrc=0x8301a4c) at php_domxml.c:337
#2  0x81425aa in list_entry_destructor (ptr=0x8301a4c) at zend_list.c:177
#3  0x8142706 in zend_destroy_rsrc_list (ht=0x820ba9c) at zend_list.c:248
#4  0x8136b68 in shutdown_executor () at zend_execute_API.c:190
#5  0x813da12 in zend_deactivate () at zend.c:595
#6  0x8091f18 in php_request_shutdown (dummy=0x0) at main.c:736
#7  0x8145a26 in apache_php_module_main (r=0x82c5034, display_source_mode=0)
at sapi_apache.c:96
#8  0x8090356 in send_php ()
#9  0x80903af in send_parsed_php ()
#10 0x81619f3 in ap_invoke_handler ()
#11 0x8175539 in process_request_internal ()
#12 0x817559c in ap_process_request ()
#13 0x816cb6e in child_main ()



[2001-09-18 08:34:12] [EMAIL PROTECTED]

tested with 4.0.7rc2

when CDATA is used in a ATTLIST tag, php crashes while trying to parse it into a 
xmltree or xmldocfile.

XML file:



  
  
  

  
  

  

  
]>









Script:
$fd = fopen($file,"r");
$myXML = fread($fd,filesize($file));
fclose($fd);
$docTree = xmltree($myXML);

gdb backtrace using apache and static php 4.0.6 will be here "real soon now"(tm)
(probably today though)





Edit this bug report at http://bugs.php.net/?id=13364&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Bug #13364 Updated: Add support for ATTLIST

2001-11-30 Thread mfischer

ID: 13364
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Summary: PHP crashes when CDATA is used in a  tag
Status: Open
Old Bug Type: DOM XML related
Bug Type: Feature/Change Request
Operating System: Debian x86 unstable
PHP Version: 4.0.6
Old Assigned To: 
Assigned To: mfischer
New Comment:

Fix for crash is coming, but yet this is a feature request to support ATTLIST.

Assigned to me.

Previous Comments:


[2001-09-18 08:47:01] [EMAIL PROTECTED]

Program received signal SIGSEGV, Segmentation fault.
node_list_wrapper_dtor (node=0x82f5b80) at php_domxml.c:315
warning: Source file is more recent than executable.

315 if (!node || node->type == XML_DTD_NODE)
(gdb) bt
#0  node_list_wrapper_dtor (node=0x82f5b80) at php_domxml.c:315
#1  0x809ce58 in php_free_xml_doc (rsrc=0x8301a4c) at php_domxml.c:337
#2  0x81425aa in list_entry_destructor (ptr=0x8301a4c) at zend_list.c:177
#3  0x8142706 in zend_destroy_rsrc_list (ht=0x820ba9c) at zend_list.c:248
#4  0x8136b68 in shutdown_executor () at zend_execute_API.c:190
#5  0x813da12 in zend_deactivate () at zend.c:595
#6  0x8091f18 in php_request_shutdown (dummy=0x0) at main.c:736
#7  0x8145a26 in apache_php_module_main (r=0x82c5034, display_source_mode=0)
at sapi_apache.c:96
#8  0x8090356 in send_php ()
#9  0x80903af in send_parsed_php ()
#10 0x81619f3 in ap_invoke_handler ()
#11 0x8175539 in process_request_internal ()
#12 0x817559c in ap_process_request ()
#13 0x816cb6e in child_main ()



[2001-09-18 08:34:12] [EMAIL PROTECTED]

tested with 4.0.7rc2

when CDATA is used in a ATTLIST tag, php crashes while trying to parse it into a 
xmltree or xmldocfile.

XML file:



  
  
  

  
  

  

  
]>









Script:
$fd = fopen($file,"r");
$myXML = fread($fd,filesize($file));
fclose($fd);
$docTree = xmltree($myXML);

gdb backtrace using apache and static php 4.0.6 will be here "real soon now"(tm)
(probably today though)





Edit this bug report at http://bugs.php.net/?id=13364&edit=1


-- 
PHP Development Mailing List 
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 #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread Markus Fischer

This has something ..

Jani, don't you think this should be investigated ..?

I thought this was made consistent or so or maybe it is
and I just don't get the picture.

- Markus

On Fri, Nov 30, 2001 at 08:13:59AM -, [EMAIL PROTECTED] wrote : 
> ID: 14294
> User updated by: [EMAIL PROTECTED]
> Reported By: [EMAIL PROTECTED]
> Status: Bogus
> Bug Type: Filesystem function related
> Operating System: FreeBSD 4.3
> PHP Version: 4.1.0
> New Comment:
> 
> You don't think it's odd that the function that checks to see if a directory exists 
>returns a warning on what it's supposed to be doing??
> 
> Earlier versions of PHP did not do this, and to me that makes it a 'bug'. While yes, 
>it can be suppressed, it should be functional in the same way previous versions of 
>PHP worked. This in no way is a 'feature' of the function.
> 
> Previous Comments:
> 
> 
> [2001-11-30 02:43:04] [EMAIL PROTECTED]
> 
> (or using @ in front of  the function)
> 
> 
> 
> 
> [2001-11-30 02:42:49] [EMAIL PROTECTED]
> 
> Warnings can be supressed by setting error_reporting correctly.
> Not a bug.
> 
> 
> 
> 
> [2001-11-29 21:28:20] [EMAIL PROTECTED]
> 
> In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says 
>"stat failed on /your/path" if the path does not exist.
> 
> This was causing havok with scripts of mine that relied on no output for errors.. Of 
>course I just suppressed the message, but it really shouldnt be there. The function 
>is designed to check for an existing dir, it should work without warnings!
> 
> Hopefully this can be fixed in the next release.
> 
> On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However 
>the version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work!
> 
> Thanks guys.
> 
> 
> 
> 
> 
> Edit this bug report at http://bugs.php.net/?id=14294&edit=1
> 
> 
> -- 
> PHP Development Mailing List 
> 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 
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-QA] PHP 4.1.0RC4

2001-11-30 Thread Sebastian Bergmann

Tobias Schenck wrote:
> Short time after the announcement just disappeared. I don't know about 
> the traffic on php-center.de or phpwelt.de (was on one of the sites) 
> but quite a couple of people not tracking php.dev might have 
> downloaded it.

  PHP-Center.de, for which I am a author and editor, had at no time a
  news bulleting and / or a download link for PHP 4.1.0 online.

  I don't know about phpwelt.de (I never visit that one...), but
  PHP-Homepage.de had a news bulleting regarding PHP 4.1.0 online.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] mail

2001-11-30 Thread Chamarty Prasanna Kumar



 

--- Begin Message ---



Hi all,

   using mail() function to send a mail using php.

I want to send that mail so that the receiver should

not see the FROM address or the mail should go without

any FROM address.

Please write with an example !!

Thanking You,

Regards,

Kumar.   
  
 


--- End Message ---

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


[PHP-DEV] Bug #14294 Updated: is_dir() causes stat failed warning

2001-11-30 Thread mike

ID: 14294
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Filesystem function related
Operating System: FreeBSD 4.3
PHP Version: 4.1.0
New Comment:

You don't think it's odd that the function that checks to see if a directory exists 
returns a warning on what it's supposed to be doing??

Earlier versions of PHP did not do this, and to me that makes it a 'bug'. While yes, 
it can be suppressed, it should be functional in the same way previous versions of PHP 
worked. This in no way is a 'feature' of the function.

Previous Comments:


[2001-11-30 02:43:04] [EMAIL PROTECTED]

(or using @ in front of  the function)




[2001-11-30 02:42:49] [EMAIL PROTECTED]

Warnings can be supressed by setting error_reporting correctly.
Not a bug.




[2001-11-29 21:28:20] [EMAIL PROTECTED]

In PHP 4.1 RC3 (non CVS release), the is_dir() function causes a warning that says 
"stat failed on /your/path" if the path does not exist.

This was causing havok with scripts of mine that relied on no output for errors.. Of 
course I just suppressed the message, but it really shouldnt be there. The function is 
designed to check for an existing dir, it should work without warnings!

Hopefully this can be fixed in the next release.

On a side note, PHP 4.1 (CVS version) does not install under FreeBSD 4.3. However the 
version available at http://www.php.net/~zeev/php-4.1.0RC3.tar.gz does work!

Thanks guys.





Edit this bug report at http://bugs.php.net/?id=14294&edit=1


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]