#47065 [NEW]: function session_unset() reset local variables

2009-01-11 Thread opurahman at gmail dot com
From: opurahman at gmail dot com
Operating system: Linux
PHP version:  5.2.8
PHP Bug Type: Session related
Bug description:  function session_unset() reset local variables

Description:

function session_unset() reset local variables.
I was trying to reset session variables after storing two values from
session. It reset my local variables. Lets take a look into the codes
bellow.

Reproduce code:
---
session_start();
$message = sprintf('%s', $_SESSION['message']);

echo('Here Message: # ' . $message . '');

session_unset();

echo('Here Message: # ' . $message . ''); // in this line, the
variable $message has been unset.

Expected result:

It should display the value of $message


-- 
Edit bug report at http://bugs.php.net/?id=47065&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47065&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47065&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47065&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47065&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47065&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47065&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47065&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47065&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47065&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47065&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47065&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47065&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47065&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47065&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47065&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47065&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47065&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47065&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47065&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47065&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47065&r=mysqlcfg



#46960 [Asn->Csd]: Actual location (location was relayed)

2009-01-11 Thread dmitry
 ID:   46960
 Updated by:   dmi...@php.net
 Reported By:  rutekp at freelance-worker dot net
-Status:   Assigned
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Centos 5 x64
 PHP Version:  5.2.8
 Assigned To:  dmitry
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

The bug is already fixed in PHP-5.3 with Garbage Collector which
collects cyclic references. In PHP-5.2 this bug will never fixed.

You can get the same memory leaks with smaller script:



In case your script creates cyclic structures, in 5.2 it's better to
break cycles before exit manually.




Previous Comments:


[2008-12-28 08:37:47] rutekp at freelance-worker dot net

Description:

When I try to excedue code which is below without:
$array["foo"] = null;
$array["blah"] = null;

have errors like 
Actual location (location was relayed)
Freeing 0x05298E00



Reproduce code:
---
--TEST--
Test session_encode() function : variation
--SKIPIF--

--FILE--

--EXPECTF--
*** Testing session_encode() : variation ***
bool(true)
string(64) 
"data|a:5:{i:0;i:1;i:1;i:2;i:2;i:3;s:3:"foo";R:1;s:4:"blah";R:1;}"
bool(true)
Done


Actual result:
--
[Thu Oct 30 20:56:43 2008]  Script: 
'ext/session/tests/session_encode_variation5.phpt'
/root/src/php-5.2.6/Zend/zend_vm_execute.h(3565) :  Freeing 0x05293DD8
(24 bytes), script=ext/session/tests/session_encode_variation5.phpt
Last leak repeated 2 times
[Thu Oct 30 20:56:43 2008]  Script: 
'ext/session/tests/session_encode_variation5.phpt'
/root/src/php-5.2.6/Zend/zend_vm_execute.h(3610) :  Freeing 0x05298CC8
(72 bytes), script=ext/session/tests/session_encode_variation5.phpt
/root/src/php-5.2.6/Zend/zend_API.c(827) : Actual location (location
was relayed)
Last leak repeated 1 time
[Thu Oct 30 20:56:43 2008]  Script: 
'ext/session/tests/session_encode_variation5.phpt'
/root/src/php-5.2.6/Zend/zend_vm_execute.h(3596) :  Freeing 0x05298E00
(71 bytes), script=ext/session/tests/session_encode_variation5.phpt
/root/src/php-5.2.6/Zend/zend_hash.c(388) : Actual location (location
was relayed)
Last leak repeated 2 times
[Thu Oct 30 20:56:43 2008]  Script: 
'ext/session/tests/session_encode_variation5.phpt'
/root/src/php-5.2.6/Zend/zend_execute.c(834) :  Freeing 0x05299050 (24
bytes), script=ext/session/tests/session_encode_variation5.phpt
[Thu Oct 30 20:56:43 2008]  Script: 
'ext/session/tests/session_encode_variation5.phpt'
/root/src/php-5.2.6/Zend/zend_hash.c(247) :  Freeing 0x052990C0 (75
bytes), script=ext/session/tests/session_encode_variation5.phpt
Last leak repeated 1 time
=== Total 11 memory leaks detected ===





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



#46850 [Asn->Bgs]: compile time depends on runtime constants ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION

2009-01-11 Thread dmitry
 ID:   46850
 Updated by:   dmi...@php.net
 Reported By:  moo dot tinys at gmail dot com
-Status:   Assigned
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: *
 PHP Version:  5.3CVS-2008-12-12 (CVS)
 Assigned To:  dmitry
 New Comment:

NULL, TRUE and FALSE may never be redefined in namespaces. So it's safe
to always substitute them at compile time.



Previous Comments:


[2009-01-09 19:07:22] s...@php.net

I'm not sure why you need to clean up EG(zend_constants). Together with
runtime constants it also contains such constants as null, which has
special "privilege" of being resolved at compile-time, since they are
always the same and have special meaning. 



[2008-12-12 14:57:17] moo dot tinys at gmail dot com

Description:

let's focus our eyes on
  zend_compile.c function zend_do_receive_arg
void zend_do_receive_arg(zend_uchar op, const znode *var, const znode
*offset, const znode *initialization, znode *class_type, const znode
*varname, zend_uchar pass_by_reference TSRMLS_DC)
{
...
   if (op == ZEND_RECV_INIT) {
   if (Z_TYPE(initialization->u.constant) == IS_NULL ||
(Z_TYPE(initialization->u.constant) == IS_CONSTANT &&
!strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))) {
   cur_arg_info->allow_null = 1;
   } else {
   zend_error(E_COMPILE_ERROR, "Default value for
parameters with a class type hint can only be NULL");
   }
   }
==
(the following gdb input/output is still using macro for your reading,
expand the macro if you want to execute)

test case 1
precondition: CG(compiler_options) |=
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION; before zend_compile_file
break at function zend_do_receive_arg and
(gdb) print Z_TYPE(initialization->u.constant) == IS_NULL
1 (true)
which means php still subst "null" to "IS_NULL"

test case 2
precondtion: let's assume ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is
working for zend_do_receive_arg, simply empty hash table:
EG(zend_constants) = &an_empty_hash_table; before zend_compile_file
break at function zend_do_receive_arg and
(gdb) print Z_TYPE(initialization->u.constant) == IS_NULL
0 (false)
(gdb) print Z_TYPE(initialization->u.constant) == IS_CONSTANT
0 (false)

so what is that?
(gdb) print Z_TYPE(initialization->u.constant)
24
(gdb) print (Z_TYPE(initialization->u.constant) &
IS_CONSTANT_TYPE_MASK) == IS_CONSTANT
1 (true)
 ok, we get the first bug
(gdb) p !strcasecmp(Z_STRVAL(initialization->u.constant), "NULL"))
0 (false)
why?
(gdb) p Z_STRVAL(initialization->u.constant)
"My\\NS\\null"
this is the reason. looks likestrcasecmp is not enough here at compile
time. or you could just handle abc(array $a = null) as a special case?

Reproduce code:
---
test.php


i don't think it easy to make a reproduce code, because
in case 1: ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is disabled until you
change it in extension or patch php for testing
and in case 2: even if you enable
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION, php is still free to access
EG(zend_constants), EG(zend_constants) has to be empty to see the bug.
see "actual result"

there's a simple patch to reproduce it. (not fix)
Index: zend_language_scanner.l
===
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131.2.11.2.13.2.32
diff -u -r1.131.2.11.2.13.2.32 zend_language_scanner.l
--- zend_language_scanner.l 4 Nov 2008 15:58:51 -  
1.131.2.11.2.13.2.32
+++ zend_language_scanner.l 12 Dec 2008 14:54:47 -
@@ -311,6 +311,8 @@

 ZEND_API zend_op_array *compile_file(zend_file_handle *file_handle,
int type TSRMLS_DC)
 {
+   HashTable empty_hash, *old_hash;
+
zend_lex_state original_lex_state;
zend_op_array *op_array = (zend_op_array *)
emalloc(sizeof(zend_op_array));
zend_op_array *original_active_op_array = CG(active_op_array);
@@ -320,6 +322,12 @@
znode retval_znode;
zend_bool original_in_compilation = CG(in_compilation);

+   CG(compiler_options) |= ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION;
+   zend_hash_init(&empty_hash, 1, NULL, NULL, 0);
+   old_hash = EG(zend_constants);
+   EG(zend_constants) = &empty_hash;
+   fprintf(stderr, "asdfasdf\n\n");
+
retval_znode.op_type = IS_CONST;
retval_znode.u.constant.type = IS_LONG;
retval_znode.u.constant.value.lval = 1;
@@ -364,6 +372,10 @@
if (compilation_successful) {
zend_restore_lexical_state(&original_lex_state TSRMLS_CC);
}
+
+   zend_hash_destroy(&empty_hash);
+   EG(zend_constants) = old_hash;
+
return retval;
 }



Expected result:

in case 1: when ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is enabled,
"null" (code) should not be resolved to "null" (val

#47066 [NEW]: Entity reference parsing broken since libxml 2.5.x

2009-01-11 Thread tstarling at wikimedia dot org
From: tstarling at wikimedia dot org
Operating system: Linux
PHP version:  5.2.8
PHP Bug Type: XML related
Bug description:  Entity reference parsing broken since libxml 2.5.x

Description:

The xml extension (xml_parser_create() etc) has totally broken entity
reference parsing when compiled with a modern libxml2 library. This appears
to be due to some clueless code inserted in compat.c 1.37 (November 2004)

http://cvs.php.net/viewvc.cgi/php-src/ext/xml/compat.c?r1=1.36&r2=1.37&pathrev=PHP_5_2

parser->parser->wellFormed = 0;

parser->wellFormed is set to 1 by libxml's xmlInitParserCtxt(), and then
to 0 by all the error cases that make the document not well-formed. Setting
wellFormed=0, before parsing even begins, means that all input is
unconditionally considered to be not well formed. This probably causes all
sorts of bugs, but the present one is an interaction with libxml2 r1177:

http://svn.gnome.org/viewvc/libxml2/trunk/parser.c?r1=1176&r2=1177&;

At line 5174 on the right, entities such as "<" encountered while
wellFormed==0 are ignored. 

Simply removing the quoted line from compat.c fixes the bug, without
breaking any unit tests.

Reported to Wikimedia at
https://bugzilla.wikimedia.org/show_bug.cgi?id=16554

Reproduce code:
---
Compile libxml2 from source, version 2.5 or later, and link it to PHP with
--with-libxml-dir.

a



Expected result:

a
<
b


Actual result:
--
a
b


-- 
Edit bug report at http://bugs.php.net/?id=47066&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47066&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47066&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47066&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47066&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47066&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47066&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47066&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47066&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47066&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47066&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47066&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47066&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47066&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47066&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47066&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47066&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47066&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47066&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47066&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47066&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47066&r=mysqlcfg



#46792 [Asn->Fbk]: SoapFault detail property missing

2009-01-11 Thread dmitry
 ID:   46792
 Updated by:   dmi...@php.net
 Reported By:  daniel dot oconnor at gmail dot com
-Status:   Assigned
+Status:   Feedback
 Bug Type: SOAP related
 Operating System: Windows
 PHP Version:  5.2.7
 Assigned To:  dmitry
 New Comment:

I don't think we should create empty "detail" property (and then encode
it and send back to client) if it's not important. Very rare script
looks into fault details. In case your script really needs it, it can
always check it with isset() or empty().


Previous Comments:


[2008-12-31 17:39:13] fel...@php.net

Hi Dmitry, any objection?
http://felipe.ath.cx/diff/bug46792.diff



[2008-12-08 00:06:24] daniel dot oconnor at gmail dot com

Description:

If you don't supply a detail param in the constructor of SoapFault, the
property doesn't exist.

See also bug #39357

Reproduce code:
---


  string(0) ""
  ["string:private"]=>
  string(0) ""
  ["code:protected"]=>
  int(0)
  ["file:protected"]=>
  string(17) "C:\soap_fault.php"
  ["line:protected"]=>
  int(2)
  ["trace:private"]=>
  array(0) {
  }
  ["faultstring"]=>
  string(0) ""
  ["detail"]=>
  string(8) "Details!"
}
object(SoapFault)#2 (7) {
  ["message:protected"]=>
  string(0) ""
  ["string:private"]=>
  string(0) ""
  ["code:protected"]=>
  int(0)
  ["file:protected"]=>
  string(17) "C:\soap_fault.php"
  ["line:protected"]=>
  int(6)
  ["trace:private"]=>
  array(0) {
  }
  ["faultstring"]=>
  string(0) ""
}





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



#47057 [Asn->Bgs]: Inconsitent namespace resolving when using dynamic class instanciation

2009-01-11 Thread dmitry
 ID:   47057
 Updated by:   dmi...@php.net
 Reported By:  tobias dot john at fondsnet dot de
-Status:   Assigned
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Mac OS X 10.5
 PHP Version:  5.3CVS-2009-01-09 (CVS)
 Assigned To:  dmitry
 New Comment:

Namespaces is a compile time feature. In run-time you should always use
full qualified names. You can use a special constant __NAMESPACE__ to do
it.

$classname2 = __NAMESPACE__ . '\foo\bar\Baz';



Previous Comments:


[2009-01-09 17:39:14] tobias dot john at fondsnet dot de

Description:

When using a variable to instantiate a class, the behavior in namespace
resolving is inconsistent to the behavior when using a static class
name.

Reproduce code:
---
namespace foo\bar;

class Baz {
public $value;

public function __construct($v) {
$this->value = $v;
}

public function echoValue() {
echo 'Value: ' . $this->value, PHP_EOL;
}
}

$classname1 = '\foo\bar\Baz';
$classname2 = 'foo\bar\Baz';

$a = new $classname1('A');
$a->echoValue();
$b = new $classname2('B');
$b->echoValue();
$c = new \foo\bar\Baz('C');
$c->echoValue();
$d = new foo\bar\Baz('D');
$d->echoValue();

Expected result:

Value: A

Fatal error: Class 'foo\bar\foo\bar\Baz' not found in
/Users/tj/Documents/workspace/yeti/lib/yeti/NamespaceTest.php on line
20


Actual result:
--
Value: A
Value: B
Value: C

Fatal error: Class 'foo\bar\foo\bar\Baz' not found in
/Users/tj/Documents/workspace/yeti/lib/yeti/NamespaceTest.php on line
24






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



#47067 [NEW]: NULL is set or unset value?

2009-01-11 Thread farkow at gmail dot com
From: farkow at gmail dot com
Operating system: Windows/WAMP Server
PHP version:  5.2.8
PHP Bug Type: Unknown/Other Function
Bug description:  NULL is set or unset value?

Description:

I realized it when i try someting about my web-based game, when you set an
integer NULL, it is same with 0 and ''.


Reproduce code:
---
';
if($x == '') echo 'UPPS 2';
if($x === '') echo 'UPPS 3';
?>

Expected result:

//output


Actual result:
--
//output
UPPS 1
UPPS 2

-- 
Edit bug report at http://bugs.php.net/?id=47067&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47067&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47067&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47067&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47067&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47067&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47067&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47067&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47067&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47067&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47067&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47067&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47067&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47067&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47067&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47067&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47067&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47067&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47067&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47067&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47067&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47067&r=mysqlcfg



#46792 [Fbk->Opn]: SoapFault detail property missing

2009-01-11 Thread daniel dot oconnor at gmail dot com
 ID:   46792
 User updated by:  daniel dot oconnor at gmail dot com
 Reported By:  daniel dot oconnor at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: SOAP related
 Operating System: Windows
 PHP Version:  5.2.7
 Assigned To:  dmitry
 New Comment:

Not having the property defined was surprising, and unexpected - I
would not expect code which reads SoapFault::$detail to ever generate an
E_NOTICE.


Previous Comments:


[2009-01-11 09:40:03] dmi...@php.net

I don't think we should create empty "detail" property (and then encode
it and send back to client) if it's not important. Very rare script
looks into fault details. In case your script really needs it, it can
always check it with isset() or empty().



[2008-12-31 17:39:13] fel...@php.net

Hi Dmitry, any objection?
http://felipe.ath.cx/diff/bug46792.diff



[2008-12-08 00:06:24] daniel dot oconnor at gmail dot com

Description:

If you don't supply a detail param in the constructor of SoapFault, the
property doesn't exist.

See also bug #39357

Reproduce code:
---


  string(0) ""
  ["string:private"]=>
  string(0) ""
  ["code:protected"]=>
  int(0)
  ["file:protected"]=>
  string(17) "C:\soap_fault.php"
  ["line:protected"]=>
  int(2)
  ["trace:private"]=>
  array(0) {
  }
  ["faultstring"]=>
  string(0) ""
  ["detail"]=>
  string(8) "Details!"
}
object(SoapFault)#2 (7) {
  ["message:protected"]=>
  string(0) ""
  ["string:private"]=>
  string(0) ""
  ["code:protected"]=>
  int(0)
  ["file:protected"]=>
  string(17) "C:\soap_fault.php"
  ["line:protected"]=>
  int(6)
  ["trace:private"]=>
  array(0) {
  }
  ["faultstring"]=>
  string(0) ""
}





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



#47067 [Opn]: NULL is set or unset value?

2009-01-11 Thread farkow at gmail dot com
 ID:   47067
 User updated by:  farkow at gmail dot com
 Reported By:  farkow at gmail dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Windows/WAMP Server
 PHP Version:  5.2.8
 New Comment:

In description, i used a wrong word, sorry for my English.
It is not 'integer', i mean 'variable'.


Previous Comments:


[2009-01-11 10:44:36] farkow at gmail dot com

Description:

I realized it when i try someting about my web-based game, when you set
an integer NULL, it is same with 0 and ''.


Reproduce code:
---
';
if($x == '') echo 'UPPS 2';
if($x === '') echo 'UPPS 3';
?>

Expected result:

//output


Actual result:
--
//output
UPPS 1
UPPS 2





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



#47042 [Opn->Csd]: php cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache

2009-01-11 Thread dsp
 ID:   47042
 Updated by:   d...@php.net
 Reported By:  sriram dot natarajan at sun dot com
-Status:   Open
+Status:   Closed
 Bug Type: CGI related
 Operating System: linux , solaris
 PHP Version:  5.2.8
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:


[2009-01-08 22:19:12] sriram dot natarajan at sun dot com

previous patch had whitespaces instead of tabs causing the patch to
appear distorted. 

posting a same patch with this issue addressed
--- sapi/cgi/cgi_main.c.ORIGThu Jan  8 14:18:25 2009
+++ sapi/cgi/cgi_main.c Thu Jan  8 14:18:31 2009
@@ -960,7 +960,9 @@
TRANSLATE_SLASHES(env_document_root);
}
 
-   if (env_path_translated != NULL &&
env_redirect_url != NULL) {
+   if (env_path_translated != NULL &&
env_redirect_url != NULL && 
+   orig_script_filename != NULL &&
script_path_translated != NULL &&
+   strcmp(orig_script_filename,
script_path_translated) != 0) {
/* 
   pretty much apache specific.  If we
have a redirect_url
   then our script_filename and
script_name point to the



[2009-01-08 20:06:25] sriram dot natarajan at sun dot com

here is the suggested patch to address this issue

--- sapi/cgi/cgi_main.c.ORIGWed Jan  7 07:10:14 2009
+++ sapi/cgi/cgi_main.c Wed Jan  7 19:37:21 2009
@@ -960,16 +960,18 @@
TRANSLATE_SLASHES(env_document_root);
}
 
-   if (env_path_translated != NULL &&
env_redirect_url != NULL) {
-   /* 
-  pretty much apache specific.  If we
have a redirect_url
-  then our script_filename and
script_name point to the
-  php executable
-   */
-   script_path_translated =
env_path_translated;
-   /* we correct SCRIPT_NAME now in case
we don't have PATH_INFO */
-   env_script_name = env_redirect_url;
-   }
+if (env_path_translated != NULL &&
env_redirect_url != NULL &&
+orig_script_filename != NULL &&
script_path_translated != NULL &&
+strcmp(orig_script_filename,
script_path_translated) != 0) {
+/*
+   pretty much apache specific.  If we
have a redirect_url
+   then our script_filename and
script_name point to the
+   php executable
+*/
+script_path_translated =
env_path_translated;
+/* we correct SCRIPT_NAME now in case
we don't have PATH_INFO */
+env_script_name = env_redirect_url;
+}



[2009-01-08 20:04:39] sriram dot natarajan at sun dot com

Description:

currently, php cgi sapi code checks for redirect url and
env_path_translated to determine if the request is coming from apache
web server and accordingly modifies the CGI environment variables so
that server can continue processing. 

however, this check is insufficient considering that any web server
exporting SCRIPT_FILENAME and REDIRECT_URL with some value will be hit
by the apache specific processing.



Reproduce code:
---
  if (env_path_translated != NULL && env_redirect_url != NULL)
{
/*
   pretty much apache specific.  If we have a
redirect_url
   then our script_filename and script_name point to
the
   php executable
*/
script_path_translated = env_path_translated;
/* we correct SCRIPT_NAME now in case we don't have
PATH_INFO */
env_script_name = env_redirect_url;
}



Expected result:

server should continue processing

Actual result:
--
no input file is returned





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



#47066 [Opn->Bgs]: Entity reference parsing broken since libxml 2.5.x

2009-01-11 Thread rrichards
 ID:   47066
 Updated by:   rricha...@php.net
 Reported By:  tstarling at wikimedia dot org
-Status:   Open
+Status:   Bogus
 Bug Type: XML related
 Operating System: Linux
 PHP Version:  5.2.8
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

Dupe of bug #45996


Previous Comments:


[2009-01-11 09:37:19] tstarling at wikimedia dot org

Description:

The xml extension (xml_parser_create() etc) has totally broken entity
reference parsing when compiled with a modern libxml2 library. This
appears to be due to some clueless code inserted in compat.c 1.37
(November 2004)

http://cvs.php.net/viewvc.cgi/php-src/ext/xml/compat.c?r1=1.36&r2=1.37&pathrev=PHP_5_2

parser->parser->wellFormed = 0;

parser->wellFormed is set to 1 by libxml's xmlInitParserCtxt(), and
then to 0 by all the error cases that make the document not well-formed.
Setting wellFormed=0, before parsing even begins, means that all input
is unconditionally considered to be not well formed. This probably
causes all sorts of bugs, but the present one is an interaction with
libxml2 r1177:

http://svn.gnome.org/viewvc/libxml2/trunk/parser.c?r1=1176&r2=1177&;

At line 5174 on the right, entities such as "<" encountered while
wellFormed==0 are ignored. 

Simply removing the quoted line from compat.c fixes the bug, without
breaking any unit tests.

Reported to Wikimedia at
https://bugzilla.wikimedia.org/show_bug.cgi?id=16554

Reproduce code:
---
Compile libxml2 from source, version 2.5 or later, and link it to PHP
with --with-libxml-dir.

a



Expected result:

a
<
b


Actual result:
--
a
b






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



#45996 [Asn->Csd]: libxml2 2.7.1 causes breakage with character data in xml_parse()

2009-01-11 Thread rrichards
 ID:   45996
 Updated by:   rricha...@php.net
 Reported By:  phpbugs at colin dot guthr dot ie
-Status:   Assigned
+Status:   Closed
 Bug Type: XML related
 Operating System: Mandriva Linux
 PHP Version:  5.2.6
 Assigned To:  rrichards
 New Comment:

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

This fix also requires the soon to be released libxml2-2.7.3 or higher

when using 2.7.x.


Previous Comments:


[2009-01-03 04:03:53] david+phpbugs at midrange dot com

Ok, I'm going to try and rebuild the Fedora 8 source RPM to avoid the
libxml2 bug ... but I'm not all that familiar with how PHP is built ...
and could use a pointer or two on what to change on the configure
command line.

Any suggestions?



[2009-01-02 23:03:29] geoffers+phpbugs at gmail dot com

What is the recommended advice for PHP software that relies upon the
XML 
extension? It'd be easier to say that libxml2.7.0–2.7.2 wasn't
supported 
if it weren't for the fact that I've had at least one user come who had

LIBXML_VERSION equal to 20632 with this issue — we can't just add a 
LIBXML_VERSION based workaround, not just because the constant doesn't

exist on 4.3.0, but also because it is seemingly isn't reliable.



[2009-01-01 20:09:07] phpbugs at colin dot guthr dot ie

If the Fedora packages do not work then this is a RedHat packaging
problem and you should complain to them/open a bug etc. etc.

Like I say, in Mandriva we made sure we provided packages that worked
because they were compiled with expat.



[2009-01-01 19:31:49] alex at peoples dot ru

Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel
on my server. I tried use 'yum remove' libxml2 and add new, but off
course this is stupid and doesn't work. I liked Linux, as the easiest
and powerful system, but now, I'm stock. I haven't any idea how I can
remove libxml2 and build new system with old one. One idea - change
system on Fedora 9, because FC 10 have the same bug with fucking
libxml2. Sorry, I was at Data Center 8 hours and I had problem with
servers with new system. I don't like updates now... they have bugs
every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New
Year. I'll never ever will update my systems less when half year.



[2008-12-31 15:22:17] scott...@php.net

Guys please READ the report, this is a bug in libxml NOT a bug in PHP.



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

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



#47067 [Opn->Bgs]: NULL is set or unset value?

2009-01-11 Thread colder
 ID:   47067
 Updated by:   col...@php.net
 Reported By:  farkow at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Windows/WAMP Server
 PHP Version:  5.2.8
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

That's expected, please check out:
http://php.net/types.comparisons


Previous Comments:


[2009-01-11 10:57:53] farkow at gmail dot com

In description, i used a wrong word, sorry for my English.
It is not 'integer', i mean 'variable'.



[2009-01-11 10:44:36] farkow at gmail dot com

Description:

I realized it when i try someting about my web-based game, when you set
an integer NULL, it is same with 0 and ''.


Reproduce code:
---
';
if($x == '') echo 'UPPS 2';
if($x === '') echo 'UPPS 3';
?>

Expected result:

//output


Actual result:
--
//output
UPPS 1
UPPS 2





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



#46997 [Com]: Column Name Based Result Fetching Causes Access Violation

2009-01-11 Thread allan at malwis dot dk
 ID:   46997
 Comment by:   allan at malwis dot dk
 Reported By:  dangerousdave86 at hotmail dot com
 Status:   Feedback
 Bug Type: MySQLi related
 Operating System: Windows Server 2008 Std ISAPI
 PHP Version:  5.2.8
 New Comment:

I have the error when trying to fetch more then one column.

Environment:
OS: WIN XP PRO 5.1.2600 SP3
PHP: 5.2.8
MySql: 5.1.30-community
Webserver: IIS 5.1

Only SQL statement and echo line is different in the 3 examples.
_
//This works:


select_db("");

$query = 'SELECT name FROM items';
$result = $con->query($query);
$row = $result->fetch_array(MYSQLI_ASSOC);
echo $row["name"];

$con->close();

 ?>
 
 
_
//This works:



select_db("");

$query = 'SELECT itemid FROM items';
$result = $con->query($query);
$row = $result->fetch_array(MYSQLI_ASSOC);
echo $row["itemid"];

$con->close();

 ?>
 
 
_
//This fails:



select_db("");

$query = 'SELECT itemid, name FROM items';
$result = $con->query($query);
$row = $result->fetch_array(MYSQLI_ASSOC);
//This line gives PHP has encountered an Access Violation at 00FA2BEB
echo $row["itemid"];

$con->close();

 ?>
 
 
_


Previous Comments:


[2009-01-05 11:54:15] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2009-01-03 13:58:33] dangerousdave86 at hotmail dot com

Description:

Error: PHP has encountered an Access Violation at 00322BEB When calling
mysqli_fetch_assoc or mysqli_fetch_object on mysqli result. Also occurs
using OO method.

Error does not occur when using mysqli_fetch_row. Result is correct and
indexed numerically in array.

Reproduce code:
---
Any database query using mysql that fetches rows using
mysql_fetch_object, _fetch_assoc, _fetch_array. Or OO equivilents.

Expected result:

an array representing a row from the database

Actual result:
--
Access Violation





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



#47068 [NEW]: Parse error if global namespace resolution is used

2009-01-11 Thread ninzya at inbox dot lv
From: ninzya at inbox dot lv
Operating system: Windows XP
PHP version:  5.3.0alpha3
PHP Bug Type: Scripting Engine problem
Bug description:  Parse error if global namespace resolution is used

Description:

See details below

Reproduce code:
---
index.php:

 1: 

Expected result:

Passed

Actual result:
--
Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9

-- 
Edit bug report at http://bugs.php.net/?id=47068&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47068&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47068&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47068&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47068&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47068&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47068&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47068&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47068&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47068&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47068&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47068&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47068&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47068&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47068&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47068&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47068&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47068&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47068&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47068&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47068&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47068&r=mysqlcfg



#47068 [Opn]: Parse error if global namespace resolution is used

2009-01-11 Thread ninzya at inbox dot lv
 ID:   47068
 User updated by:  ninzya at inbox dot lv
 Reported By:  ninzya at inbox dot lv
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  5.3.0alpha3
 New Comment:

This used to work in PHP 5.3.0alpha2


Previous Comments:


[2009-01-11 15:20:54] ninzya at inbox dot lv

Description:

See details below

Reproduce code:
---
index.php:

 1: 

Expected result:

Passed

Actual result:
--
Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9





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



#47069 [NEW]: Expecting T_VARIABLE in catch block

2009-01-11 Thread ninzya at inbox dot lv
From: ninzya at inbox dot lv
Operating system: Windows XP
PHP version:  5.3.0alpha3
PHP Bug Type: Scripting Engine problem
Bug description:  Expecting T_VARIABLE in catch block

Description:

See details below. This used to work with PHP 5.3.0alpha2

Reproduce code:
---
index.php:

1: 

Expected result:

No parse errors

Actual result:
--
Parse error: parse error, expecting `T_VARIABLE' in
D:\WebServer\PHP-5.3a3\index.php on line 5

-- 
Edit bug report at http://bugs.php.net/?id=47069&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47069&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47069&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47069&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47069&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47069&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47069&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47069&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47069&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47069&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47069&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47069&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47069&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47069&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47069&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47069&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47069&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47069&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47069&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47069&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47069&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47069&r=mysqlcfg



#47068 [Opn->Bgs]: Parse error if global namespace resolution is used

2009-01-11 Thread felipe
 ID:   47068
 Updated by:   fel...@php.net
 Reported By:  ninzya at inbox dot lv
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  5.3.0alpha3
 New Comment:

Hi,
the namespace separator was changed to \.
http://docs.php.net/manual/en/language.namespaces.basics.php


Previous Comments:


[2009-01-11 15:21:49] ninzya at inbox dot lv

This used to work in PHP 5.3.0alpha2



[2009-01-11 15:20:54] ninzya at inbox dot lv

Description:

See details below

Reproduce code:
---
index.php:

 1: 

Expected result:

Passed

Actual result:
--
Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9





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



#47069 [Opn->Bgs]: Expecting T_VARIABLE in catch block

2009-01-11 Thread felipe
 ID:   47069
 Updated by:   fel...@php.net
 Reported By:  ninzya at inbox dot lv
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  5.3.0alpha3
 New Comment:

The same to bug #47068.

Thanks.


Previous Comments:


[2009-01-11 15:25:06] ninzya at inbox dot lv

Description:

See details below. This used to work with PHP 5.3.0alpha2

Reproduce code:
---
index.php:

1: 

Expected result:

No parse errors

Actual result:
--
Parse error: parse error, expecting `T_VARIABLE' in
D:\WebServer\PHP-5.3a3\index.php on line 5





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



#47068 [Bgs]: Parse error if global namespace resolution is used

2009-01-11 Thread ninzya at inbox dot lv
 ID:   47068
 User updated by:  ninzya at inbox dot lv
 Reported By:  ninzya at inbox dot lv
 Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows XP
 PHP Version:  5.3.0alpha3
 New Comment:

A BACKSLASH? FAIL. That's very very BAD idea. The code has become NOT
readable, it looks like HDD DISK DUMP, FILE LIST, CRAP. It would be good
if you change your mind about NS separator before releasing 5.3.0 and
leave "::" as ns sep., or at least pick dot (".") or something, NOT
BACKSLASH.

I suggest you less chatting with your collegues and more chat with
people when deciding about things like namespace separators. I have read
your wiki, where devs suggest ":)", "^^", "**", "%%" as separators -
that's not serious. What's wrong with "::"? Why it was necessary to
change it to something like backslash? Backslash is the last thing u
should implement in this case.

I'm completely not comfortable with use of backslash as separator, and
100% of other people i guess too.


Previous Comments:


[2009-01-11 16:20:27] fel...@php.net

Hi,
the namespace separator was changed to \.
http://docs.php.net/manual/en/language.namespaces.basics.php



[2009-01-11 15:21:49] ninzya at inbox dot lv

This used to work in PHP 5.3.0alpha2



[2009-01-11 15:20:54] ninzya at inbox dot lv

Description:

See details below

Reproduce code:
---
index.php:

 1: 

Expected result:

Passed

Actual result:
--
Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9





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



#47002 [Com]: Fields truncated

2009-01-11 Thread typoon at gmail dot com
 ID:   47002
 Comment by:   typoon at gmail dot com
 Reported By:  victorjavierss at live dot com dot mx
 Status:   Open
 Bug Type: dBase related
 Operating System: Windows
 PHP Version:  5.2CVS-2009-01-04 (snap)
 New Comment:

I was unable to find a free version of dBase so I can't really create
the file here to simulate the issue.
Could you please post a link to a .dbf file with more than 1024 fields
for me please? Put like 3 or 4 records as examples on it, just so I can
do all tests.

Thanks!

Henrique


Previous Comments:


[2009-01-04 22:17:20] victorjavierss at live dot com dot mx

Description:

I'm executing the code belong, and it supose to retrieve me 1625
fields, but it doesn't, it give me 1024 fields, also i tried with other
dbf's bigger than 1024 and the problem stills there



Reproduce code:
---


Expected result:

1625

Actual result:
--
1024





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



#47002 [Opn]: Fields truncated

2009-01-11 Thread victorjavierss at live dot com dot mx
 ID:   47002
 User updated by:  victorjavierss at live dot com dot mx
 Reported By:  victorjavierss at live dot com dot mx
 Status:   Open
 Bug Type: dBase related
 Operating System: Windows
 PHP Version:  5.2CVS-2009-01-04 (snap)
 New Comment:

Here is one of the DBF's that i'm using:

http://cid-d95738776c6cf0d0.skydrive.live.com/self.aspx/.Public/USAERF07.DBF

as I said it retrieves me 1024 fild instead of 1625


Previous Comments:


[2009-01-11 18:50:14] typoon at gmail dot com

I was unable to find a free version of dBase so I can't really create
the file here to simulate the issue.
Could you please post a link to a .dbf file with more than 1024 fields
for me please? Put like 3 or 4 records as examples on it, just so I can
do all tests.

Thanks!

Henrique



[2009-01-04 22:17:20] victorjavierss at live dot com dot mx

Description:

I'm executing the code belong, and it supose to retrieve me 1625
fields, but it doesn't, it give me 1024 fields, also i tried with other
dbf's bigger than 1024 and the problem stills there



Reproduce code:
---


Expected result:

1625

Actual result:
--
1024





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



#30924 [Com]: move_uploaded_file() misbehaves

2009-01-11 Thread a1bert at atlas dot cz
 ID:   30924
 Comment by:   a1bert at atlas dot cz
 Reported By:  himself at zhwau dot net
 Status:   No Feedback
 Bug Type: Filesystem function related
 Operating System: Windows XP
 PHP Version:  5.0.2
 New Comment:

I am experiencing simillar issue:

move_uploaded_file() launches warning about:
"move_uploaded_file() [function.move-uploaded-file]: open_basedir 
restriction in effect. File(/var/tmp/php/phpDvi4ra) is not within 
the allowed path(s):"

but returns success and file is successfully moved (even when 
replacing existing file)

PHP Version 5.2.0-8+etch13


Previous Comments:


[2006-12-01 04:28:58] alex at mintpixels dot com

oops - hit tab then space, so it submitted before I was done:

if (move_uploaded_file($_FILES['worksheet_new']['tmp_name'],$location))
{
  echo "Success";
} else {
  echo "Failure";
}

This prints the warning message, then "Success" when executed.



[2006-12-01 04:27:36] alex at mintpixels dot com

I have created a simple test case:








posts to 

";
if (move_uploaded_file($_FILES['worksheet_new']['tmp_name'],$location))
{

}



[2006-12-01 04:17:49] alex at mintpixels dot com

I can also confirm that this is a problem in 5.2.0.

I am using move_uploaded_file to move a file from /tmp/ to
/worksheets/3.jpg

On the initial upload, I get no openbase_dir message, and the file
writes successfully and the function returns true (as I expected).

On the second upload to the file (where the file exists already), I get
an openbase_dir error message in the error log and the file does not
write successfully, but the function still returns a true value anyway
(not as expected).

I have also witnessed a case where I get no openbase_dir message and
the new file writes successfully.  
I verified this by checking the file size had changed between requests
(as I had uploaded a different file), which it had.  But I am now unable
to reproduce that problem.

In all cases however the function is returning true.

I am using PHP 5.2.0 on Apache 2.0.59 on Linux 2.6.9-42.0.2.ELsmp i686
athlon i386 GNU/Linux.

The permissions of the directory/file are clearly correct because the
first upload is writing correctly.  I have also verified the permissions
independently by doing $h=fopen("$docroot/worksheets/3.jpg");
fwrite($h,"test"); fclose($h);
The file is created and contains the line as expected.


In line with the guidelines, I have downloaded the latest build from
CVS, and the following behaviour has changed.

I now get an open_basedir warning message on the initial upload in the
log, but the file is written anyway, and the function still returns
true.

the same behaviour persists with the second upload.



[2005-02-19 01:00:21] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2005-02-11 23:20:52] tony2...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip





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

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



#47033 [Opn->Bgs]: converting binary<->string without charset translating

2009-01-11 Thread johannes
 ID:   47033
 Updated by:   johan...@php.net
 Reported By:  lunter at interia dot pl
-Status:   Open
+Status:   Bogus
 Bug Type: Unicode Engine related
 Operating System: all
 PHP Version:  6CVS-2009-01-08 (snap)
 New Comment:

We have unicode_encode() / unicode_decode().


Previous Comments:


[2009-01-08 07:42:45] lunter at interia dot pl

Description:

converting binary<->string without charset translating


Two functions for converting binary<->string without translating
charset needed.
It is very usefull because binary data can consists utf-8 substring,
you need to convert to string type.
Also when you have to see binary representation of utf-8 string, or
operating on it as binaries.


Example 1:

You have (binary)$b. It consists two bytes: 11001110 10110010
Its length in binary representation is two.
It is also valid one-length UTF-8 char(946) (greek small letter beta)
How to conver it ($b) into one-char UTF-8 string??
When we try $u=(string)$b, it gives two-char UTF-8 string.


Example 2:

You have (string)$u UTF-8 one-char string. It consists chr(946) (greek
small letter beta)
Now You have to see two bytes binary representation of this (11001110
10110010).
There is no way to convert it without charset translation...




Reproduce code:
---

; Unicode settings ;


unicode.semantics = off
unicode.runtime_encoding = iso-8859-1
unicode.script_encoding = utf-8
unicode.output_encoding = utf-8
unicode.from_error_mode = U_INVALID_SUBSTITUTE
unicode.from_error_subst_char = 3f




Expected result:

way to converting binary<->string without charset translating



Actual result:
--
no way to converting binary<->string without charset translating








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



#47034 [Opn->Bgs]: Prepared-Statement fails when MySQL-Server under load

2009-01-11 Thread johannes
 ID:   47034
 Updated by:   johan...@php.net
 Reported By:  raphithom at gmx dot ch
-Status:   Open
+Status:   Bogus
 Bug Type: MySQLi related
 Operating System: FreeBSD 6.3-RELEASE-p5
 PHP Version:  5.2.8
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This error is coming from the server which has to handle it's
resources. The reason PDO works is that PDO uses an emulation for
prepared statements by default, falling back to simple queries.


Previous Comments:


[2009-01-08 09:20:51] raphithom at gmx dot ch

I forgot to mention, that the mysqldumps are running on other
databases, not on the one where I'm executing the prepared statement.



[2009-01-08 08:57:44] raphithom at gmx dot ch

Description:

Hello

As backup-procedure we use 4 concurrent mysql-dump processes. When
these processes are running, MySQLi-Prepared-Statements can't be
executed and the following error appears:

Errno: 1615
Message: Prepared statement needs to be re-prepared

In my opinion it doesn't seem to be a mysql-problem because
prepared-statements with PDO and "normal" mysql_query() or
mysqli->query() work as expected. The error doesn't occur if no
mysqldumps are running. 

Reproduce code:
---
http://tmp.raphis.ch/mysqli_problem.phps

Expected result:

All queries should return the same texts.

Actual result:
--
mysqli-select, mysql_select and PDO work as expected. mysqli-prepared
statements exits with:

Errno: 1615
Message: Prepared statement needs to be re-prepared





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



#47065 [Opn->Bgs]: function session_unset() reset local variables

2009-01-11 Thread johannes
 ID:   47065
 Updated by:   johan...@php.net
 Reported By:  opurahman at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.8
 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


Note: If $_SESSION (or $HTTP_SESSION_VARS  for PHP 4.0.6 or less) is
used, use unset() to unregister a session variable, i.e. unset
($_SESSION['varname']);. 

session_unset() is to be ued when using register_globals() which is not
advised.


Previous Comments:


[2009-01-11 08:37:22] opurahman at gmail dot com

Description:

function session_unset() reset local variables.
I was trying to reset session variables after storing two values from
session. It reset my local variables. Lets take a look into the codes
bellow.

Reproduce code:
---
session_start();
$message = sprintf('%s', $_SESSION['message']);

echo('Here Message: # ' . $message . '');

session_unset();

echo('Here Message: # ' . $message . ''); // in this line, the
variable $message has been unset.

Expected result:

It should display the value of $message






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



#36853 [Com]: Worker process crashes after application pool recycle

2009-01-11 Thread sdavey at datalink dot com dot au
 ID:   36853
 Comment by:   sdavey at datalink dot com dot au
 Reported By:  kleef84 at hotmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 SP1
 PHP Version:  5CVS-2006-03-24 (CVS)
 New Comment:

There have been a few bugs reported for this issue over a few years,
and the most current and active one seems to be Bug #38111. I suggest
everyone head over there and votes for it.

It is also open and awaiting a backtrace.  The problem appears that the
crash is not directly the result of PHP code being executed, but rather
the result of IIS cleaning up worker proccesses with PHP ISAPI running
in them and DEP preventing some code execution at that time.  This makes
generating a backtrace difficult, and thus the bug has been around for a
number of years.

To help people with this issue, a number of workarounds have been
discovered over the years:
- Add w3wp.exe to DEP exclusion list 
- Turn off process recycling in IIS
- Use FastCGI rather than ISAPI


Previous Comments:


[2007-05-24 17:44:21] linhardt at aol dot com

I have this problem too, but it has nothing to do with PHP as I'm
running ASP.NET.

My environment is:
MS Windows 2003 Server + SP2
IIS 6.0.3790.3959
.NET 2.0.50727

I get both:

Faulting application w3wp.exe, version 6.0.3790.1830, faulting module
unknown, version 0.0.0.0, fault address 0x01bba980.

and

Data Execution Prevention – Microsoft Windows
To help protect your computer, Windows has closed this program. 
Name: IIS Worker Process
Publisher: program publisher



[2006-10-18 01:32:46] kamikazie at comcast dot net

I've noticed this error, too, but only after a PHP page has been
loaded.

Same basic setup as most, Server 2003, IIS 6, PHP 5.1.4,  painstakingly
followed the setup instructions.

Now a webpage that loads only HTML does not give this error.  When I
load a page that calls PHP, it throws this error about 5 to 10 minutes
after the first page is loaded.



[2006-07-12 14:25:19] ferrante at aracnet dot com

Windows 2003 Server, IIS6, .NET 1.1 & .NET 2.0,
php5.2-win32-200607120630 from the snapshots. (Fully Microsoft patched
Windows 2003 server machine).

Even with all PHP dynamic extensions turned off, crash occurs during
IISreset or w3svc service restart.

Event as it appears in event log:

Event Type: Error
Event Source:   Application Error
Event Category: (100)
Event ID:   1000
Date:   07/12/2006
Time:   06:26:45
User:   N/A
Computer:   COMPUTER-NAME
Description:
Faulting application w3wp.exe, version 6.0.3790.1830, faulting module
unknown, version 0.0.0.0, fault address 0x01bba980.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.
Data:
: 41 70 70 6c 69 63 61 74   Applicat
0008: 69 6f 6e 20 46 61 69 6c   ion Fail
0010: 75 72 65 20 20 77 33 77   ure  w3w
0018: 70 2e 65 78 65 20 36 2e   p.exe 6.
0020: 30 2e 33 37 39 30 2e 31   0.3790.1
0028: 38 33 30 20 69 6e 20 75   830 in u
0030: 6e 6b 6e 6f 77 6e 20 30   nknown 0
0038: 2e 30 2e 30 2e 30 20 61   .0.0.0 a
0040: 74 20 6f 66 66 73 65 74   t offset
0048: 20 30 31 62 62 61 39 3801bba98
0050: 300   



Visual Studio 2005 Debugger gives this for the stack trace:
*1  01bba980()
 2  msvcrt.dll!__endthread() 
 3  kernel32.dll!_basethreadst...@8()

WinDBG gives this:
+0x26a980
msvcrt!endthread+0xab
kernel32!GetModuleFileNameA+0xeb

the Debug Diagnostic Tool gives this
Function Arg 1 Arg 2 Arg 3   Source 
+26a980 01782ee8     

msvcrt!endthread+ab 02108c80  
kernel32!GetModuleFileNameA+eb 77bcb35a 02108c80 



[2006-07-12 09:54:10] ferrante at aracnet dot com

These are related issues that seem to be describing the same problem:
Bug #33373 IIS worker Process continually restarts
Bug #37575 Faulting application w3wp.exe
Bug #35263 Crash during IIS Restart

Adding the w3wp.exe process to the DEP exception list will also mask
the problem.



[2006-05-28 17:42:23] sschefer at scheferonline dot net

Deeper investigation of the problem indicates that the reason you are
now getting this is because of .NET 2.0. In verison 1.0 and 1.1 it did
not throw this exception because it was set to ignore it. If you don't
have any security issues, you could probably just ignore them and be
O.K. That would not be my choice.

The solution is to recompile the DLL's (all of them) with Visual Studio
8. This will then correctly place them within the scope of the IIS
authorized extension list. 

Workaround, back 

#38111 [Com]: PHP crashes IIS worker process and application pool

2009-01-11 Thread scott at datalink dot com dot au
 ID:   38111
 Comment by:   scott at datalink dot com dot au
 Reported By:  svendavidh at hotmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 Std. Ed. R2
 PHP Version:  5.2.8
 Assigned To:  pajoye
 New Comment:

To help people with this issue, I've scanned all the PHP bugs relating
to this issue and collated a list of workarounds:
- Add w3wp.exe to DEP exclusion list 
- Turn off process recycling
- Use FastCGI rather than ISAPI

To the PHP team - you guys are great and I love your work. I know you
haven't gotten the backtrace, but please don't mark this bug as bogus. 
The community is trying to get what you need and have been very patient
with this issue, but it appears to be difficult to get  because of the
way it crashes.


Previous Comments:


[2009-01-09 22:17:18] damon at clarkweb dot com

Same problems with PHP 5.2.8 on Vista SP1.  Following SIKLE's steps 
reproduces the bug every time.  This has been open far too long for 
an easily reproducable bug.  Please address!



[2009-01-04 10:46:52] sikle at stx dot net 

Oh here's a 100% repro:

1. Load a php program. For example, I just go to
http://localhost/phpmyadmin, I then logon to my database, and then I
just close the browser.

2. Now go into IIS, on the left side double click on the computer name
and then you'll see "Application Pools", now click on it.

3. Now click on "DefaultAppPool" and then on the right side of the
screen you'll see "Recycle..." click on it.

Now after you clicked on "Recycle...", within about 4 seconds you'll
see the crash: "IIS Worker Process has stopped working".

Whoever fixes this bug will be my personal hero.



[2009-01-04 10:31:17] sikle at stx dot net

Dear programmers,

Please fix this bug :~( (with a cherry on top?) I'm on PHP 5.2.8 and it
happens all the time (on average 5-6 times a day) and it's very
annoying. Like the others have mentioned I assume this is a memory
bug that is triggered when IIS recycles its application pool.



[2008-12-27 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2008-12-22 02:41:45] todd at lanlocked dot net

Just following up:

I believe it is 1740 seconds, not minutes
I am running IIS 7 on Server 2008 Std 64 bit
PHP is running outside of the default app pool, although in trying to
resolve the issue I set it up with the default app pool and it did the
same thing

Could someone let me know how to backtrace the correct process (I
assume I have to backtrace an IIS worker process) and we can get it
sorted?



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

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



#38111 [NoF]: PHP crashes IIS worker process and application pool

2009-01-11 Thread pajoye
 ID:   38111
 Updated by:   paj...@php.net
 Reported By:  svendavidh at hotmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows Server 2003 Std. Ed. R2
 PHP Version:  5.2.8
 Assigned To:  pajoye
 New Comment:

"- Use FastCGI rather than ISAPI"

that's definitively the way to go :) 


Previous Comments:


[2009-01-11 23:44:21] scott at datalink dot com dot au

To help people with this issue, I've scanned all the PHP bugs relating
to this issue and collated a list of workarounds:
- Add w3wp.exe to DEP exclusion list 
- Turn off process recycling
- Use FastCGI rather than ISAPI

To the PHP team - you guys are great and I love your work. I know you
haven't gotten the backtrace, but please don't mark this bug as bogus. 
The community is trying to get what you need and have been very patient
with this issue, but it appears to be difficult to get  because of the
way it crashes.



[2009-01-09 22:17:18] damon at clarkweb dot com

Same problems with PHP 5.2.8 on Vista SP1.  Following SIKLE's steps 
reproduces the bug every time.  This has been open far too long for 
an easily reproducable bug.  Please address!



[2009-01-04 10:46:52] sikle at stx dot net 

Oh here's a 100% repro:

1. Load a php program. For example, I just go to
http://localhost/phpmyadmin, I then logon to my database, and then I
just close the browser.

2. Now go into IIS, on the left side double click on the computer name
and then you'll see "Application Pools", now click on it.

3. Now click on "DefaultAppPool" and then on the right side of the
screen you'll see "Recycle..." click on it.

Now after you clicked on "Recycle...", within about 4 seconds you'll
see the crash: "IIS Worker Process has stopped working".

Whoever fixes this bug will be my personal hero.



[2009-01-04 10:31:17] sikle at stx dot net

Dear programmers,

Please fix this bug :~( (with a cherry on top?) I'm on PHP 5.2.8 and it
happens all the time (on average 5-6 times a day) and it's very
annoying. Like the others have mentioned I assume this is a memory
bug that is triggered when IIS recycles its application pool.



[2008-12-27 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



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

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



#47070 [NEW]: php_stream_locate_url_wrapper fails without authority section

2009-01-11 Thread darrel dot opry at gmail dot com
From: darrel dot opry at gmail dot com
Operating system: Ubuntu 8.10
PHP version:  5.2.8
PHP Bug Type: Streams related
Bug description:  php_stream_locate_url_wrapper fails without authority section

Description:

php_stream_locate_url_wrapper fails without authority section.

If a URL is not in the Common Internet Scheme Syntax
(scheme://<:@>host<:port>/url-path) the scheme is not be
located properly. So URLs of scheme:relative/path and scheme:/absolute/path
will not be handled by the registered user defined stream wrapper.

see http://www.ietf.org/rfc/rfc1738.txt for URL specific syntax.

see section 3 of http://labs.apache.org/webarch/uri/rfc/rfc3986.html#intro
for URI syntax.

Reproduce code:
---
 public:path/file.txt
[1] => r+
[2] => 4
[3] => 
)
Array
(
[0] => public:/path/file.txt
[1] => r+
[2] => 4
[3] => 
)
Array
(
[0] => public://path/file.txt
[1] => r+
[2] => 4
[3] => 
)

Actual result:
--
Warning: fopen(public:path/file.txt): failed to open stream: No such file
or directory in
/home/dopry/public_html/drupal-media/sites/default/modules/media/resource/test.php
on line 13

Warning: fopen(public:/path/file.txt): failed to open stream: No such file
or directory in
/home/dopry/public_html/drupal-media/sites/default/modules/media/resource/test.php
on line 14
Array
(
[0] => public://path/file.txt
[1] => r+
[2] => 4
[3] => 
)


-- 
Edit bug report at http://bugs.php.net/?id=47070&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47070&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47070&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47070&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47070&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47070&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47070&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47070&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47070&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47070&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47070&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47070&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47070&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47070&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47070&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47070&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47070&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47070&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47070&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47070&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47070&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47070&r=mysqlcfg



#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)

2009-01-11 Thread Tyron dot Delean at unisa dot edu dot au
 ID:   42060
 Comment by:   Tyron dot Delean at unisa dot edu dot au
 Reported By:  iarenuno at eteo dot mondragon dot edu
 Status:   Assigned
 Bug Type: LDAP related
 Operating System: *
 PHP Version:  5CVS, 6CVS (2008-11-01)
 Assigned To:  pajoye
 New Comment:

I really really really really need Paging support for PHP LDAP calls.
This is a super super super high priority for me to get an App working.
Could somebody please tell me when the support for Paged Results from
LDAP calls will be available, and what version of PHP will support it. I
have checked the latest source versions for PHP 5.3 & PHP 6.0 snapshots
and can't see it in there. I hope I am missing something. Extremely
concerned.

Tyron


Previous Comments:


[2009-01-03 20:48:50] nelg at linuxsolutions dot co dot nz

Hi,

I am really keen to see this patch applied, as without it, the is some
things that cannot easily be done in LDAP with PHP.   Any progress? 
last comment seems to indicate it was going to be committed soon, but I
don't see it in the php source tree yet.



[2008-11-16 23:22:00] iarenuno at eteo dot mondragon dot edu

pajoye,

thanks a lot for your work to get this patch into core. This was a much
needed feature in big LDAP installations.

Saludos. Iñaki.



[2008-11-16 14:57:56] paj...@php.net

Alexey has ported the patch to 5.3, it will committed in the next days.



[2008-11-16 14:24:12] aklmnop at gmail dot com

It would be great to have this essential paging functionality, and it's

about time to update PHP's ldap. LDAP isn't going anywhere, and this
has 
been waiting for long enough. Just because a myopic maintainer doesn't

use LDAP doesn't mean it's not extremely widespread, urgent and 
important. Thanks.



[2008-07-17 13:00:37] ando at sys-net dot it

I didn't get any notification about this message, so I overlooked it; I
was pointed here by a user (like many others) interested in the
functionalities provided by the patch.  In the meanwhile, I noticed that
the code, after more than 2 years of inactivity, is now incompatible
with the patch.  Fixing it will require an amount of time that is
incompatible with my current schedule.  Feel free to fix it yourself. 
Cheers, p.



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

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



#47071 [NEW]: Charset problem

2009-01-11 Thread freelas at gmail dot com
From: freelas at gmail dot com
Operating system: all
PHP version:  5.2.8
PHP Bug Type: SimpleXML related
Bug description:  Charset problem

Description:

In response for a bug 40433. Specially for chr...@php.net


Sorry, but I'm thinking you're stupid. You can't see the problem that this
wrong behaviour it's causing and you're replying this as a man tha has crap
on brain and not have a minimum respect.

UTF-8 isn't the unique charset in the world and PHP language can loose
some programmers and enterprises who likes this language cause you do a
stupid response for a stupid bug instead of rethinking it.

If the libxml2 doesn't support at least the charsets most used in the
world and you change to this lib you aren't thinking who this causes to us
and to you. And it isn't documented on SimpleXML manual.

I use this class in a big project. I'm using iso-8859-1 and I was affected
for this BUG (yes. for me and for a lot of programmers a wrong behaviour is
a bug even it was thinked before relese it). But I look at the problem
later and I needed to do a stupid conversion always decreasing the system
performance.

Learn to speak correctly with your clients before reply a bug. Programmers
make enterprise decisions for what language use to code a system,
programmers buy PHP books, help your code, submit bugs, buy certifications,
zend features and others thinks. Then, respect us.




-- 
Edit bug report at http://bugs.php.net/?id=47071&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47071&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47071&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47071&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47071&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=47071&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47071&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=47071&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=47071&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=47071&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=47071&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=47071&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=47071&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=47071&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47071&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=47071&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47071&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=47071&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=47071&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=47071&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=47071&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=47071&r=mysqlcfg



#47065 [Bgs]: function session_unset() reset local variables

2009-01-11 Thread opurahman at gmail dot com
 ID:   47065
 User updated by:  opurahman at gmail dot com
 Reported By:  opurahman at gmail dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.8
 New Comment:

OK then delete this topic please.


Previous Comments:


[2009-01-11 22:31:21] johan...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


Note: If $_SESSION (or $HTTP_SESSION_VARS  for PHP 4.0.6 or less) is
used, use unset() to unregister a session variable, i.e. unset
($_SESSION[\'varname\']);. 

session_unset() is to be ued when using register_globals() which is not
advised.



[2009-01-11 08:37:22] opurahman at gmail dot com

Description:

function session_unset() reset local variables.
I was trying to reset session variables after storing two values from
session. It reset my local variables. Lets take a look into the codes
bellow.

Reproduce code:
---
session_start();
$message = sprintf('%s', $_SESSION['message']);

echo('Here Message: # ' . $message . '');

session_unset();

echo('Here Message: # ' . $message . ''); // in this line, the
variable $message has been unset.

Expected result:

It should display the value of $message






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



#47071 [Opn->Csd]: Charset problem

2009-01-11 Thread freelas at gmail dot com
 ID:   47071
 User updated by:  freelas at gmail dot com
 Reported By:  freelas at gmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: SimpleXML related
 Operating System: all
 PHP Version:  5.2.8
 New Comment:

?


Previous Comments:


[2009-01-12 06:09:08] freelas at gmail dot com

Description:

In response for a bug 40433. Specially for chr...@php.net


Sorry, but I'm thinking you're stupid. You can't see the problem that
this wrong behaviour it's causing and you're replying this as a man tha
has crap on brain and not have a minimum respect.

UTF-8 isn't the unique charset in the world and PHP language can loose
some programmers and enterprises who likes this language cause you do a
stupid response for a stupid bug instead of rethinking it.

If the libxml2 doesn't support at least the charsets most used in the
world and you change to this lib you aren't thinking who this causes to
us and to you. And it isn't documented on SimpleXML manual.

I use this class in a big project. I'm using iso-8859-1 and I was
affected for this BUG (yes. for me and for a lot of programmers a wrong
behaviour is a bug even it was thinked before relese it). But I look at
the problem later and I needed to do a stupid conversion always
decreasing the system performance.

Learn to speak correctly with your clients before reply a bug.
Programmers make enterprise decisions for what language use to code a
system, programmers buy PHP books, help your code, submit bugs, buy
certifications, zend features and others thinks. Then, respect us.








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