Bug #52316 [Fbk-Asn]: Macro redefinition with Visual Studio 2010

[hendrik dot schmieder at jedox dot com]

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

 ID:   52316
 User updated by:  hendrik dot schmieder at jedox dot com
 Reported by:  hendrik dot schmieder at jedox dot com
 Summary:  Macro redefinition with Visual Studio 2010
-Status:   Feedback
+Status:   Assigned
 Type: Bug
 Package:  Compile Warning
 Operating System: Windows
 PHP Version:  5.2.13
 Assigned To:  pajoye

 New Comment:

I speak about 5.2.x and in 5.2.14RC2 it is still not fixed.


Previous Comments:

[2010-07-12 16:29:20] paj...@php.net

Is it not fixed already in 5.3?


[2010-07-12 16:19:21] hendrik dot schmieder at jedox dot com

Description:

With Visual Studio 2010 you get the warning.



...\tsrm\readdir.h(10): warning C4005: '_WIN32_WINNT' : macro
redefinition

  C:\Programme\Microsoft
SDKs\Windows\v7.0A\include\sdkddkver.h(197) : see previous definition of
'_WIN32_WINNT'







Changing in readdir.h



#define _WIN32_WINNT 0x0400



to



#ifndef _WIN32_WINNT

#define _WIN32_WINNT 0x0400

#endif



would solve the problem.











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

Bug #52316 [Asn-Fbk]: Macro redefinition with Visual Studio 2010

[pajoye]

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

 ID:   52316
 Updated by:   paj...@php.net
 Reported by:  hendrik dot schmieder at jedox dot com
 Summary:  Macro redefinition with Visual Studio 2010
-Status:   Assigned
+Status:   Feedback
 Type: Bug
 Package:  Compile Warning
 Operating System: Windows
 PHP Version:  5.2.13
 Assigned To:  pajoye

 New Comment:

Let me rephrase: 5.2 supports only VC6.



That means you can try with 5.3 (which should be fixed).


Previous Comments:

[2010-07-13 09:36:46] hendrik dot schmieder at jedox dot com

I speak about 5.2.x and in 5.2.14RC2 it is still not fixed.


[2010-07-12 16:29:20] paj...@php.net

Is it not fixed already in 5.3?


[2010-07-12 16:19:21] hendrik dot schmieder at jedox dot com

Description:

With Visual Studio 2010 you get the warning.



...\tsrm\readdir.h(10): warning C4005: '_WIN32_WINNT' : macro
redefinition

  C:\Programme\Microsoft
SDKs\Windows\v7.0A\include\sdkddkver.h(197) : see previous definition of
'_WIN32_WINNT'







Changing in readdir.h



#define _WIN32_WINNT 0x0400



to



#ifndef _WIN32_WINNT

#define _WIN32_WINNT 0x0400

#endif



would solve the problem.











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

Bug #49937 [Com]: [PATCH] Race condition in PDOStatement

[kkaminski at itens dot pl]

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

 ID:   49937
 Comment by:   kkaminski at itens dot pl
 Reported by:  basa...@php.net
 Summary:  [PATCH] Race condition in PDOStatement
 Status:   Assigned
 Type: Bug
 Package:  PDO related
 Operating System: Linux
 PHP Version:  5.2.11
 Assigned To:  basantk

 New Comment:

Any chances of getting this patch into PHP 5.2.14? Or getting a windows
build for testing?

I'd like to give it a try but having problems building PHP under
winblows :/


Previous Comments:

[2009-11-17 02:51:36] basa...@php.net

Here is the link to the patch which I submitted in previous

comments. 

http://bitbucket.org/basantk/phpbugs/raw/5c3ca3a306ed/pdo_bug_52trunk.txt



Marking the bug as Patch available.


[2009-10-23 18:15:51] basa...@php.net

Here is a revised patch which is much less invasive, restricts totally
to pdo.

Fix is to avoid using shared zval ptr

(PdoStatement-ce-propertiers{queryString}) in multiple PdoStatement

objects.  Instead it creates a copy of the null zval for individual
object.



This fix the race condition for me and have been verified by one of the
olio

php customer.  I ran the pdo_sqlite tests and didn't find any
regression.



Here is the fix

-



Index: ext/pdo/pdo_stmt.c

===

--- ext/pdo/pdo_stmt.c  (revision 289806)

+++ ext/pdo/pdo_stmt.c  (working copy)

@@ -2312,6 +2312,54 @@

return -1;

 }

 

+static void init_stmt_properties(pdo_stmt_t* stmt TSRMLS_DC)

+{

+   HashTable* ht =  stmt-ce-default_properties;

+   HashTable* target = stmt-properties;

+

+   HashPosition pos;

+   zend_hash_internal_pointer_reset_ex(ht, pos);

+   while(zend_hash_has_more_elements_ex(ht, pos)

+   == SUCCESS) {

+   ulong index;

+   char* key = NULL;

+   uint keylen = 0;

+   int ret = zend_hash_get_current_key_ex(ht,

+   
   key,

+   
   keylen,

+   
   index, 0,

+   
   pos);

+   if ((keylen == sizeof(queryString))

+(strncmp(key, queryString, keylen) == 0)) {

+   zval* qval;

+   /* Since the value for the key queryString in

+* stmt-ce-default_properties is shared by multiple 
threads so

+* we can not add the same zval in stmt-properties. we 
need to

+* create a null property object. See Bug 49937 */

+   ALLOC_INIT_ZVAL(qval);

+   zend_hash_add(stmt-properties, queryString, 

+ sizeof(queryString), 
(void**) qval, sizeof(zval*), NULL);

+   }

+   else {

+   void* data = NULL;

+   zend_hash_get_current_data_ex(ht,

+   
  (void **) data, pos);

+   void *new_entry = NULL;

+   if (data) {

+   /* We expect keylen should be  0. 
default_properties hash

+* should only contain named keys */

+   if (keylen) {

+   zend_hash_quick_update(target, key, 
keylen, 0, data,
sizeof(void*), new_entry);

+   } 

+   if (new_entry) {

+   zval_add_ref(new_entry);

+   }

+   }

+   }

+   zend_hash_move_forward_ex(ht, pos);

+   }

+}

+

 static zend_object_value dbstmt_clone_obj(zval *zobject TSRMLS_DC)

 {

zend_object_value retval;

@@ -2325,7 +2373,7 @@

stmt-refcount = 1;

ALLOC_HASHTABLE(stmt-properties);

zend_hash_init(stmt-properties, 0, NULL, ZVAL_PTR_DTOR, 0);

-   zend_hash_copy(stmt-properties, stmt-ce-default_properties,
(copy_ctor_func_t) zval_add_ref, (void *) tmp, sizeof(zval *));

+   init_stmt_properties(stmt TSRMLS_CC);

 

old_stmt = (pdo_stmt_t *)zend_object_store_get_object(zobject
TSRMLS_CC);



@@ -2454,7 +2502,7 @@

stmt-refcount = 1;

ALLOC_HASHTABLE(stmt-properties);

Bug #52316 [Fbk-Asn]: Macro redefinition with Visual Studio 2010

[hendrik dot schmieder at jedox dot com]

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

 ID:   52316
 User updated by:  hendrik dot schmieder at jedox dot com
 Reported by:  hendrik dot schmieder at jedox dot com
 Summary:  Macro redefinition with Visual Studio 2010
-Status:   Feedback
+Status:   Assigned
 Type: Bug
 Package:  Compile Warning
 Operating System: Windows
 PHP Version:  5.2.13
 Assigned To:  pajoye

 New Comment:

There was never a problem compiling php extensions with VS2003 and
VS2005 and php version  5.3.

For PHP we use the supplied binaries.



Why is it so difficult to made the proposed change.

This can be done in less than one minute.

Just for the upcoming 5.2.14 version.


Previous Comments:

[2010-07-13 09:38:33] paj...@php.net

Let me rephrase: 5.2 supports only VC6.



That means you can try with 5.3 (which should be fixed).


[2010-07-13 09:36:46] hendrik dot schmieder at jedox dot com

I speak about 5.2.x and in 5.2.14RC2 it is still not fixed.


[2010-07-12 16:29:20] paj...@php.net

Is it not fixed already in 5.3?


[2010-07-12 16:19:21] hendrik dot schmieder at jedox dot com

Description:

With Visual Studio 2010 you get the warning.



...\tsrm\readdir.h(10): warning C4005: '_WIN32_WINNT' : macro
redefinition

  C:\Programme\Microsoft
SDKs\Windows\v7.0A\include\sdkddkver.h(197) : see previous definition of
'_WIN32_WINNT'







Changing in readdir.h



#define _WIN32_WINNT 0x0400



to



#ifndef _WIN32_WINNT

#define _WIN32_WINNT 0x0400

#endif



would solve the problem.











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

Bug #52316 [Asn-Wfx]: Macro redefinition with Visual Studio 2010

[pajoye]

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

 ID:   52316
 Updated by:   paj...@php.net
 Reported by:  hendrik dot schmieder at jedox dot com
 Summary:  Macro redefinition with Visual Studio 2010
-Status:   Assigned
+Status:   Wont fix
 Type: Bug
 Package:  Compile Warning
 Operating System: Windows
 PHP Version:  5.2.13
 Assigned To:  pajoye

 New Comment:

5.2 never worked with recent compilers. We do not support them either.



5.3 supports both VC6 and more recent compilers (we use VC9 and test
with VC10). Next major version will support only one (be 5.3 or 6.0).



5.2.14 is in RC phase (last one) and only very critical changes can be
applied.


Previous Comments:

[2010-07-13 10:06:53] hendrik dot schmieder at jedox dot com

There was never a problem compiling php extensions with VS2003 and
VS2005 and php version  5.3.

For PHP we use the supplied binaries.



Why is it so difficult to made the proposed change.

This can be done in less than one minute.

Just for the upcoming 5.2.14 version.


[2010-07-13 09:38:33] paj...@php.net

Let me rephrase: 5.2 supports only VC6.



That means you can try with 5.3 (which should be fixed).


[2010-07-13 09:36:46] hendrik dot schmieder at jedox dot com

I speak about 5.2.x and in 5.2.14RC2 it is still not fixed.


[2010-07-12 16:29:20] paj...@php.net

Is it not fixed already in 5.3?


[2010-07-12 16:19:21] hendrik dot schmieder at jedox dot com

Description:

With Visual Studio 2010 you get the warning.



...\tsrm\readdir.h(10): warning C4005: '_WIN32_WINNT' : macro
redefinition

  C:\Programme\Microsoft
SDKs\Windows\v7.0A\include\sdkddkver.h(197) : see previous definition of
'_WIN32_WINNT'







Changing in readdir.h



#define _WIN32_WINNT 0x0400



to



#ifndef _WIN32_WINNT

#define _WIN32_WINNT 0x0400

#endif



would solve the problem.











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

[PHP-BUG] Req #52325 [NEW]: multiple php.ini with mod_php5 allusive or impossible

[admin at digibase dot ca]

From: 
Operating system: Linux
PHP version:  Irrelevant
Package:  PHP options/info functions
Bug Type: Feature/Change Request
Bug description:multiple php.ini with mod_php5 allusive or impossible

Description:

Greetings,



I have noticed that under apache, setting php.ini-only directives (such as
disable_functions - which is not accepted in httpd.conf) per virtual host
can only be done by installing php with something like suPHP. This is not a
desirable configuration in most cases when php is already installed as
mod_php4 or mod_php5.



Furthermore, for loading php.ini files, PHPRC environment variable seems to
be ignored, as well, PHPINIDir only is accepted once per apache
configuration, even in completely different vhost blocks.



I run a shared hosting infastructure for special project sites, Now, I
would like to have a default, restricted PHP configuration, then under
certain virtual host blocks (for example, for users I approve) set up less
restricted php.ini files for those accounts.



Also, there are several internally run sites that need a very loose setup
but I would not want regular users having that setup for themselves.



The issue at the moment is for many options, PHP does not accept more than
one setup per server (oncemore, in the case of disable_functions).

Test script:
---
?

system('ls');

?

Expected result:

On one restricted vhost with options set via php.ini:

The script should return that the system() function is disabled.



On a less restricted vhost with options set via php.ini:

The script should execute the system() call. 

Actual result:
--
Either:



On one restricted vhost with options set via php.ini:

The script returns that the system() function is disabled.



On a less restricted vhost with options set via php.ini:

The script returns that the system() function is disabled.



Or:



On one restricted vhost with options set via php.ini:

The script executes the system() call. 



On a less restricted vhost with options set via php.ini:

The script executes the system() call. 



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

Req #52325 [Opn]: multiple php.ini with mod_php5 allusive or impossible

[admin at digibase dot ca]

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

 ID:   52325
 User updated by:  admin at digibase dot ca
 Reported by:  admin at digibase dot ca
 Summary:  multiple php.ini with mod_php5 allusive or impossible
 Status:   Open
 Type: Feature/Change Request
 Package:  PHP options/info functions
 Operating System: Linux
 PHP Version:  Irrelevant

 New Comment:

Just as clarification:



in my test cases,

On one restricted vhost with options set via php.ini:

On a less restricted vhost with options set via php.ini:



these lines should be regarded as:



On one restricted vhost with options set via
/etc/php/profiles/default/php.ini:

On a less restricted vhost with options set via
/etc/php/profiles/approved/php.ini:


Previous Comments:

[2010-07-13 10:22:46] admin at digibase dot ca

Description:

Greetings,



I have noticed that under apache, setting php.ini-only directives (such
as disable_functions - which is not accepted in httpd.conf) per virtual
host can only be done by installing php with something like suPHP. This
is not a desirable configuration in most cases when php is already
installed as mod_php4 or mod_php5.



Furthermore, for loading php.ini files, PHPRC environment variable seems
to be ignored, as well, PHPINIDir only is accepted once per apache
configuration, even in completely different vhost blocks.



I run a shared hosting infastructure for special project sites, Now, I
would like to have a default, restricted PHP configuration, then under
certain virtual host blocks (for example, for users I approve) set up
less restricted php.ini files for those accounts.



Also, there are several internally run sites that need a very loose
setup but I would not want regular users having that setup for
themselves.



The issue at the moment is for many options, PHP does not accept more
than one setup per server (oncemore, in the case of disable_functions).

Test script:
---
?

system('ls');

?

Expected result:

On one restricted vhost with options set via php.ini:

The script should return that the system() function is disabled.



On a less restricted vhost with options set via php.ini:

The script should execute the system() call. 

Actual result:
--
Either:



On one restricted vhost with options set via php.ini:

The script returns that the system() function is disabled.



On a less restricted vhost with options set via php.ini:

The script returns that the system() function is disabled.



Or:



On one restricted vhost with options set via php.ini:

The script executes the system() call. 



On a less restricted vhost with options set via php.ini:

The script executes the system() call. 








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

Bug #52316 [Wfx]: Macro redefinition with Visual Studio 2010

[hendrik dot schmieder at jedox dot com]

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

 ID:   52316
 User updated by:  hendrik dot schmieder at jedox dot com
 Reported by:  hendrik dot schmieder at jedox dot com
 Summary:  Macro redefinition with Visual Studio 2010
 Status:   Wont fix
 Type: Bug
 Package:  Compile Warning
 Operating System: Windows
 PHP Version:  5.2.13
 Assigned To:  pajoye

 New Comment:

I wonder, why there's a bug reporting system, if you don't care for the
bugs,

even if the bug can easily be fixed like this one.


Previous Comments:

[2010-07-13 10:18:50] paj...@php.net

5.2 never worked with recent compilers. We do not support them either.



5.3 supports both VC6 and more recent compilers (we use VC9 and test
with VC10). Next major version will support only one (be 5.3 or 6.0).



5.2.14 is in RC phase (last one) and only very critical changes can be
applied.


[2010-07-13 10:06:53] hendrik dot schmieder at jedox dot com

There was never a problem compiling php extensions with VS2003 and
VS2005 and php version  5.3.

For PHP we use the supplied binaries.



Why is it so difficult to made the proposed change.

This can be done in less than one minute.

Just for the upcoming 5.2.14 version.


[2010-07-13 09:38:33] paj...@php.net

Let me rephrase: 5.2 supports only VC6.



That means you can try with 5.3 (which should be fixed).


[2010-07-13 09:36:46] hendrik dot schmieder at jedox dot com

I speak about 5.2.x and in 5.2.14RC2 it is still not fixed.


[2010-07-12 16:29:20] paj...@php.net

Is it not fixed already in 5.3?




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/bug.php?id=52316


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

Bug #52302 [Asn-Bgs]: mysqli_fetch_all does not work with MYSQLI_USE_RESULT

[andrey]

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

 ID:   52302
 Updated by:   and...@php.net
 Reported by:  brianlm...@php.net
 Summary:  mysqli_fetch_all does not work with MYSQLI_USE_RESULT
-Status:   Assigned
+Status:   Bogus
 Type: Bug
 Package:  MySQLi related
 Operating System: Linux
 PHP Version:  5.3.2
 Assigned To:  mysql

 New Comment:

Makes no sense to use USE_RESULT and buffer the result. Use
STORE_RESULT, it is more effective for fetch_all(). Artifically limited.


Previous Comments:

[2010-07-12 18:16:35] brad at njoe dot com

Confirmed on Windows build as well using: PHP 5.3.2 (cli) (built: Mar  3
2010 

19:40:13).



Even SELECT'ing a static string (e.g. SELECT 'This is a test.') exhibits
this 

behavior.


[2010-07-10 10:39:32] brianlm...@php.net

Description:

When using MYSQLI_USE_RESULT as the second parameter to mysqli_query,
fetch_all returns null.

Test script:
---
?php



$m = new MySQLi(, root, , information_schema);



$sql = show tables;



$res = $m-query($sql, MYSQLI_USE_RESULT);



$rows = $res-fetch_all();



var_dump($rows);



?

Expected result:

An array of the table data.

Actual result:
--
NULL






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

Bug #52316 [Wfx]: Macro redefinition with Visual Studio 2010

[pajoye]

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

 ID:   52316
 Updated by:   paj...@php.net
 Reported by:  hendrik dot schmieder at jedox dot com
 Summary:  Macro redefinition with Visual Studio 2010
 Status:   Wont fix
 Type: Bug
 Package:  Compile Warning
 Operating System: Windows
 PHP Version:  5.2.13
 Assigned To:  pajoye

 New Comment:

What are you talking about? You ask something that we can't fix at this
stage. I don't think it is so hard to understand (last RC and only
critical fixes go to 5.2 from now on). We also always claimed,
advertised and documented that the only compiler we support for 5.2 is
VC6.



Now, about windows and php, if you are serious about that, then I
strongly suggest you to move to 5.3. Windows support is much better with
5.3, regular updates for the libraries, better portability, faster, more
stable. And it supports modern VC versions.


Previous Comments:

[2010-07-13 10:33:01] hendrik dot schmieder at jedox dot com

I wonder, why there's a bug reporting system, if you don't care for the
bugs,

even if the bug can easily be fixed like this one.


[2010-07-13 10:18:50] paj...@php.net

5.2 never worked with recent compilers. We do not support them either.



5.3 supports both VC6 and more recent compilers (we use VC9 and test
with VC10). Next major version will support only one (be 5.3 or 6.0).



5.2.14 is in RC phase (last one) and only very critical changes can be
applied.


[2010-07-13 10:06:53] hendrik dot schmieder at jedox dot com

There was never a problem compiling php extensions with VS2003 and
VS2005 and php version  5.3.

For PHP we use the supplied binaries.



Why is it so difficult to made the proposed change.

This can be done in less than one minute.

Just for the upcoming 5.2.14 version.


[2010-07-13 09:38:33] paj...@php.net

Let me rephrase: 5.2 supports only VC6.



That means you can try with 5.3 (which should be fixed).


[2010-07-13 09:36:46] hendrik dot schmieder at jedox dot com

I speak about 5.2.x and in 5.2.14RC2 it is still not fixed.




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/bug.php?id=52316


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

Bug #52324 [Dup]: bad result when adding two floats

[brunog at micro-examples dot com]

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

 ID:   52324
 User updated by:  brunog at micro-examples dot com
 Reported by:  brunog at micro-examples dot com
 Summary:  bad result when adding two floats
 Status:   Duplicate
 Type: Bug
 Package:  *General Issues
 Operating System: ubuntu
 PHP Version:  5.2.14RC2

 New Comment:

yes the issues you mention are connected to mine

since there are only a few operations in my source code example, and not
billions as in others, maybe it will be easier to track the bug

to me, lunar phase is a stranger to this problem but I can check again
in a few days if you like :))

I believe it is a conjonction between floating point internal
representation and float to str routine that causes problem

I have this problem on CODERO and 1AND1 dedicated servers that come with
ubuntu, so I think many other users may be impacted too

a workaround in my case would be to multiply operands by 100 and to
divide result by 100 

it seems that this issues goes back and forth depending on multiple
criteria, and may come again at any time

thank you


Previous Comments:

[2010-07-13 04:52:25] ahar...@php.net

Actually, the colon is part of the output here: we have a rare bug

that seems to be platform, architecture, compiler and optimisation

level dependent. (It may also involve the phase of the moon, but we

can't be absolutely sure -- I've never been able to reproduce it,

and I've tried pretty hard.)



Other bugs discussing this issue include bug #47716, bug #49764 and

bug #51396.


[2010-07-13 01:35:03] brunog at micro-examples dot com

strangely it works fine on an older php version 

PHP Version = 5.1.6

gives 0.1 as expected


[2010-07-13 01:16:39] ras...@php.net

It doesn't show 0.0 on any PHP version I have access to.  No idea about
your 

5.2.4.  That's from 3 years ago.  I don't have anything that old on any
of my 

machines.


[2010-07-13 01:10:58] brunog at micro-examples dot com

maybe, but 0.0: is not a correct value at all as an add result, whatever
floating point accuracy is

0.09 + 0.02 gives 0.11 as expected, neither 0.1099 nor 0.::


[2010-07-13 01:04:36] ras...@php.net

That is the correct value according to how computers store floating
point 

values.  If you want it accurate to 2 decimal places, round() it to 2
decimal 

places.  Read the big red warning box here: 

http://php.net/manual/en/language.types.float.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/bug.php?id=52324


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

Bug #52312 [Com]: PHP lstat problem

[v dot damore at gmail dot com]

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

 ID:   52312
 Comment by:   v dot damore at gmail dot com
 Reported by:  v dot damore at gmail dot com
 Summary:  PHP lstat problem
 Status:   Feedback
 Type: Bug
 Package:  Safe Mode/open_basedir
 Operating System: Linux
 PHP Version:  5.2.13

 New Comment:

Looking at source code main/main.c of 5.2.13 I can see:



1292:   /* Disable realpath cache if safe_mode or open_basedir are set 

*/

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1769:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



So realpath cache is definitely disabled in case of safe_mode or
open_basedir.

This dramatically reduce performance of PHP Engine and this behavior can
bring a 

server to its knees.

Especially because there is a lack of documentation!

Can you explain why this choose?

Must I continue debugging PHP engine in order to understand what's
happening?


Previous Comments:

[2010-07-13 01:52:37] v dot damore at gmail dot com

I found where the problem is, this behavior is not a bug.

Looking at main/main.c I found following lines:



1416:   /* Disable realpath cache if safe_mode or open_basedir
are set */

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1978:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



Could you explain why if safe_mode or open_basedir are set realpath
cache is disabled?


[2010-07-13 01:38:26] v dot damore at gmail dot com

There is a interesting update, I have found CWDG define so now we have:



(gdb) print cwd_globals.realpath_cache_size_limit

$3 = 0



Probably you should check why realpath_cache_size_limit is equal to 0


[2010-07-13 01:30:24] v dot damore at gmail dot com

After having set breakpoint tsrm_realpath_r and I have execute step by
step debug.

I think is interesting that after execution tsrm_virtual_cwd.c of line
681 execution continue on line 890.



gdb) break tsrm_realpath_r

Breakpoint 1 at 0x2b0b3c9f2702: file
/usr/local/sitipersonali/sitipersonali01/NSP_SERVICE/strillo/sources/php-5.3.2/TSRM/tsrm_virtual_cwd.c,
line 611.

(gdb) continue

Continuing.



Breakpoint 1, tsrm_realpath_r (path=0x7fffddfb32b0
/usr/local/myspace/webspace/httpdocs/test.php, start=1, len=45,
ll=0x7fffddfb32ac, t=0x7fffddfb32a0, use_realpath=2, is_dir=0,
link_is_dir=0x0)

at
/usr/local/sitipersonali/sitipersonali01/NSP_SERVICE/strillo/sources/php-5.3.2/TSRM/tsrm_virtual_cwd.c:611

611 int directory = 0;

(gdb) step

624 if (len = start) {

(gdb) step

628 i = len;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

633 if (i == len ||

(gdb) step

639 } else if (i == len - 2  path[i] == '.'  path[i+1] 
== '.') {

(gdb) step

677 path[len] = 0;

(gdb) step

679 save = (use_realpath != CWD_EXPAND);

(gdb) step

681 if (start  save  CWDG(realpath_cache_size_limit)) {

(gdb) watch save

Hardware watchpoint 2: save

(gdb) print save

$1 = 1

(gdb) print start

$2 = 1

(gdb) print realpath_cache_size_limit

No symbol 

[PHP-BUG] Bug #52327 [NEW]: base64_decode() improper handling of leading padding.

[yuri-sevatz at hotmail dot com]

From: 
Operating system: ALL
PHP version:  5.3.2
Package:  *Compression related
Bug Type: Bug
Bug description:base64_decode() improper handling of leading padding.

Description:

According to the MIME standard that we're following, this isn't supposed to
work when strict mode is enabled.  Equal-signs are strictly reserved for
padding characters at the _end_ of a base64 MIME string.



Leading '=' signs are allowed in each block of 4 bytes because the
condition that checks for invalid placement of the '=' signs only checks if
(i % 4) == 1, 



Whereas it should check if (i % 4) is 0 or 1.



You should be able to change the circumstances for a valid '=' placement,
as follows, to conform to the standard:



// to see if bit position 2 is set (for all values of i = n*4+2 and i =
n*4+3)

if (i  2)

// means that the '=' is in a valid location







I would also suggest *carefully* looking over the block at the end of the
base64_decode() function... as it seems that if (ch == base64_pad) after ch
is ALWAYS set to '\0' is an impossible scenario.

Test script:
---
?php 

echo
base64_decode('=VGhl=ICc9=JyBz=eW1i=b2xz=IGFy=ZW4n=dCBh=bGxv=d2Vk=IHdo=ZXJl=IGkg=cHV0=IHRo=ZW0g=by5P');

?



Expected result:

should return FALSE/NULL/Errornous value

Actual result:
--
echos:



The '=' symbols aren't allowed where i put them o.O

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

Bug #47304 [Com]: typecast of numeric string to float produces strange result

[ola dot andersson at liko dot se]

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

 ID:   47304
 Comment by:   ola dot andersson at liko dot se
 Reported by:  lennartvdd at mailordersolutions dot nl
 Summary:  typecast of numeric string to float produces strange
   result
 Status:   Feedback
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: win32 only
 PHP Version:  5.2.9
 Assigned To:  pajoye

 New Comment:

Thank you for your suggestion pajoye.



Neither php-5.3.2-nts-Win32-VC6-x86 or php-5.3.2-nts-Win32-VC9-x86
include the extension php_mssql.dll. Without this extension I am not
able to properly upgrade and test our systems with this version of PHP.




Howcome php_mssql is no longer included with the distributions?


Previous Comments:

[2010-07-12 13:48:17] paj...@php.net

Please try with 5.3.2 or 5.3.3RC2 VC9 version.


[2010-07-12 12:53:18] ola dot andersson at liko dot se

Error occur also when fetching data from a MS SQL server having the
column value 290.00 (database Money format). 



$query =select pris from sa_jobb_3_1 WHERE id='.$id.';

$result = mssql_query($query) or die($query);

$row = mssql_fetch_array($result,MSSQL_ASSOC);

printf(%f,$row['pris']);  



The code above outputs incorrectly 28:.00 and not as expected
290.00


[2010-07-12 12:43:14] ola dot andersson at liko dot se

The same error occurred for me. The installation is PHP 5.2.13 installed
on IIS7/Win server 2008.



Writing a script as suggested (see below) produces incorrect output for
the echo function. The error is however intermittent. 



When refreshing the browser and rerunning the script several times
(perhaps 20-40 times) the correct numbers are sometimes displayed and
sometimes the incorrect.



Script used for testing:



for ($i=0; $i400; $i++)

{

echo $i.-;

printf(%f\n,$i);

}


[2010-06-15 03:49:17] xiaobo dot bob at gmail dot com

I have a win32 program writing in delphi using the component php4delphi
that can reproduce this problem. if someone need it, i can email it to
you.



or if some one can help me to compile php under vc6 with the .dsp (I can
compile 5.3.2 using nmake of vc++9, with the step-by-step direction of
the manual, but failed to compile using .dsp project). i have tried to
use the windbg.exe with the downloaded debug pack to trace into the
code, it seems the problem happens in the function php_conv_fp in
snprintf.c, but as the local variables always memory access error, i
can't make any progress.


[2010-06-14 14:29:27] xiaobo dot bob at gmail dot com

i tried set precision to 5/14/20, and keep the serialize_precision =
100.



echo number_format(1900.0,2) is always wrong.



here is my code:



echo ini_get(precision)./.ini_get(serialize_precision).br;

echo number_format(1900.0,2).---\n;




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/bug.php?id=47304


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

Bug #50997 [Com]: SOAP Error when trying to submit 2nd Element of a choice

[sebastian at rootdir dot ws]

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

 ID:   50997
 Comment by:   sebastian at rootdir dot ws
 Reported by:  mrsharp at gmx dot de
 Summary:  SOAP Error when trying to submit 2nd Element of a
   choice
 Status:   Open
 Type: Bug
 Package:  SOAP related
 Operating System: debian
 PHP Version:  5.2.12

 New Comment:

As this still seems to be an issue, here is a complete reproducer:





$soapClient = new SoapClient('service2.wsdl', array ('trace' = 1));



$params = array('code' = 'foo');

$soapClient-newOperation($params);





WSDL excerpt:



xsd:element name=NewOperation

  xsd:complexType

   xsd:choice

 xsd:sequence

   xsd:element name=firstName type=xsd:string /xsd:element

   xsd:element name=surName type=xsd:string/

 /xsd:sequence

 xsd:element name=code type=xsd:string//xsd:choice

  /xsd:complexType

/xsd:element



(You can find the whole WSDL example file over at
http://pastebin.com/UZrPCuJt)





Actual result:



Fatal error: SOAP-ERROR: Encoding: object hasn't 'firstName' property





If you move element name code being the first child of xsd:choice
the code snippet above is working as expected.


Previous Comments:

[2010-02-11 10:22:36] mrsharp at gmx dot de

Tested also using PHP Version 5.2.5-3 same result


[2010-02-10 18:08:41] mrsharp at gmx dot de

Description:

My Actual PHP Version: PHP Version 5.2.11-0.dotdeb.0



not 100% sure if this relates to Bug #43723: SOAP not sent properly
from client for choice because SOAP is not sent at all in my scenario
(Fatal Error)



Part of my WSDL is this schema excerpt



xsd:complexType name=sometype

  xsd:choice

   xsd:group ref=sd:someGroupDefA/

   xsd:group ref=sd:someGroupDefB/

  /xsd:choice 



A SOAP operation now employs this type... if I attempt to submit a
property set which resembles someGroupDefB I receive a 



SOAP-ERROR: Encoding: object hasn't someGroupDefA property 



so it seems that choice is not properly evalutated...







Expected result:

I expect that SOAP accepts both sets of parameters without complaining
about the other missing...







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

Bug #31715 [Com]: isset() and empty() return Trying to get property of non-object

[info at steffisgarten dot de]

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

 ID:   31715
 Comment by:   info at steffisgarten dot de
 Reported by:  cryptographite at comcast dot net
 Summary:  isset() and empty() return Trying to get property of
   non-object
 Status:   Closed
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: FreeBSD
 PHP Version:  5.0.3
 Assigned To:  felipe

 New Comment:

I'm experiencing the same problem using php 5.3.2 under Ubuntu Lucid
(5.3.2-1ubuntu4.2).

This is really annoying since the isset() function is supposed to check
whether the object exists or not, so the error makes so sense for me.


Previous Comments:

[2010-01-16 01:00:00] 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.


[2010-01-08 11:07:33] ahar...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

5.1.2 is an extremely old version of PHP. Please try again with a
current version.



FWIW, I can't reproduce this with 5.2.10-whatever-Ubuntu-ship or 5.3.1
-- the only notices are to do with the use of the undefined $key
variable as an array index, which are valid. The expected output is:



$not-set-variable

isset false

empty true

--

$not-set[$key]



Notice: Undefined variable: key in /tmp/test.php on line 11

isset false



Notice: Undefined variable: key in /tmp/test.php on line 13

empty true




[2010-01-08 10:12:43] ninuhadida at gmail dot com

I am experiencing the same problem with PHP 5.1.2 on SUSE Linux


[2005-02-04 01:00:06] 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-01-27 08:12:45] der...@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/bug.php?id=31715


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

Bug #52312 [Fbk-Ana]: PHP lstat problem

[pajoye]

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

 ID:   52312
 Updated by:   paj...@php.net
 Reported by:  v dot damore at gmail dot com
 Summary:  PHP lstat problem
-Status:   Feedback
+Status:   Analyzed
 Type: Bug
 Package:  Safe Mode/open_basedir
 Operating System: Linux
 PHP Version:  5.2.13

 New Comment:

The reason was due to a security flaw involving symbolic links and
realpath cache. It allowed to bypass open_basedir when a path was
cached. The cleanest way to fix it was to disable the realpath cache
when open_basedir/safemode are set.



Thanks Johannes to remind us about this change.


Previous Comments:

[2010-07-13 11:01:23] v dot damore at gmail dot com

Looking at source code main/main.c of 5.2.13 I can see:



1292:   /* Disable realpath cache if safe_mode or open_basedir are set 

*/

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1769:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



So realpath cache is definitely disabled in case of safe_mode or
open_basedir.

This dramatically reduce performance of PHP Engine and this behavior can
bring a 

server to its knees.

Especially because there is a lack of documentation!

Can you explain why this choose?

Must I continue debugging PHP engine in order to understand what's
happening?


[2010-07-13 01:52:37] v dot damore at gmail dot com

I found where the problem is, this behavior is not a bug.

Looking at main/main.c I found following lines:



1416:   /* Disable realpath cache if safe_mode or open_basedir
are set */

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1978:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



Could you explain why if safe_mode or open_basedir are set realpath
cache is disabled?


[2010-07-13 01:38:26] v dot damore at gmail dot com

There is a interesting update, I have found CWDG define so now we have:



(gdb) print cwd_globals.realpath_cache_size_limit

$3 = 0



Probably you should check why realpath_cache_size_limit is equal to 0


[2010-07-13 01:30:24] v dot damore at gmail dot com

After having set breakpoint tsrm_realpath_r and I have execute step by
step debug.

I think is interesting that after execution tsrm_virtual_cwd.c of line
681 execution continue on line 890.



gdb) break tsrm_realpath_r

Breakpoint 1 at 0x2b0b3c9f2702: file
/usr/local/sitipersonali/sitipersonali01/NSP_SERVICE/strillo/sources/php-5.3.2/TSRM/tsrm_virtual_cwd.c,
line 611.

(gdb) continue

Continuing.



Breakpoint 1, tsrm_realpath_r (path=0x7fffddfb32b0
/usr/local/myspace/webspace/httpdocs/test.php, start=1, len=45,
ll=0x7fffddfb32ac, t=0x7fffddfb32a0, use_realpath=2, is_dir=0,
link_is_dir=0x0)

at
/usr/local/sitipersonali/sitipersonali01/NSP_SERVICE/strillo/sources/php-5.3.2/TSRM/tsrm_virtual_cwd.c:611

611 int directory = 0;

(gdb) step

624 if (len = start) {

(gdb) step

628 i = len;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

633 if (i == len ||

(gdb) step

639 } else if (i 

[PHP-BUG] Bug #52329 [NEW]: ftp_connect doesn't work on web script but works on command line

[daniel dot requena at gmail dot com]

From: 
Operating system: Centos
PHP version:  5.3.3RC2
Package:  FTP related
Bug Type: Bug
Bug description:ftp_connect doesn't work on web script but works on command line

Description:

Hi,

I have the next script:

?php

$ftp_host = '192.168.1.120';//'ftp.adrive.com';

if(!$connId = ftp_connect($ftp_host))

{

echo Not connected to {$ftp_host}!!;

}

else

{   

echo Connected!!;

ftp_close($connId);

}

?

When I call this script using command line with the next command:

php pruftp.php, I always get Connected!!, but when I call from
accessible public url as the next: http://emucent/pruftp.php I always get
Now connected to 1192.168.1.120. 

What can be the problem?

Expected result:

Connected!!

Actual result:
--
Not connected to 192.168.1.120!!

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

[PHP-BUG] Bug #52330 [NEW]: __construct() method should always return a new instance

[whistl0r+phpbug at googlemail dot com]

From: 
Operating system: 
PHP version:  Irrelevant
Package:  Class/Object related
Bug Type: Bug
Bug description:__construct() method should always return a new instance

Description:

Please see the test script. This should be normal PHP 5.3 class with a good
OOP design.



In PHP it is possible, that I can call the constructor multiple times, for
example:



$person = new \My\Person('Jens', 'Mander');

echo sprintf('Name: %s %s', $person-getName(), $person-getSurname()); //
Will output Name: Jens Mander



$person-__construct('John', 'Doe');

echo sprintf('Name: %s %s', $person-getName(), $person-getSurname()); //
Will output Name: John Doe



In my understanding, it is unexpected, that

1) you can access the constructor method in an instantiated object. The
constructor should only instantiate the object - when you have the object,
there is no need to call it again. If you need something to reset your
object state, you should implement such a method.



2) If you can call the constructor again, that it will change the object
and *not* return a new instance.



For example:

If you add a return new \stdClass(); line to your constructor, it will
still change the instance you called it from, but now it will also return a
stdClass - that's inconsistent, isn't it?

Test script:
---
?php

namespace My;



class Person

{

  protected $_name = null;

  

  protected $_surname = null;

  

  /**

  * Constructor.

  * 

  * @param  string OPTIONAL $name

  * @param  string OPTIONAL $surname

  * @return \My\Person

  */

  public function __construct($name = null, $surname = null)

  {

if ($name !== null)

{

$this-setName($name);

}



if ($surname !== null)

{

$this-setSurname($surname);

}

  }

  

  /**

  * Returns the name.

  * 

  * @return null|string Null, when no name was set

  */

  public function getName()

  {

return $this-_name;

  }

  

  /**

  * Returns the surname.

  * 

  * @return null|string Null, when no name was set

  */

  public function getSurname()

  {

return $this-_surname;

  }

  

  /**

  * Set the name.

  * 

  * @param  string $name

  * @return \My\Person Provides fluent interface

  * @throws \Exception

  */

  public function setName($name)

  {

if (!is_string($name) || empty($name))

{

  throw new \Exception('Name cannot be empty and must be a string!');

}



$this-_name = $name;





return $this;

  }

  

  /**

  * Set the surname.

  * 

  * @param string $name

  * @return \My\Person Provides fluent interface

  * @throws \Exception When $name isn't a string or empty

  */

  public function setSurname($name)

  {

if (!is_string($name) || empty($name))

{

  throw new \Exception('Name cannot be empty and must be a string!');

}



$this-_surname = $name;





return $this;

  }

}

Expected result:

- FATAL error e.g. Object already constructed!



- The __construct() call should return a *new* object.

Actual result:
--
The __construct() method will work on the object, from where you called it.

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

Bug #52317 [Opn-Asn]: Segmentation fault when using mail() on a rhel 4.x (only 64 bit)

[aharvey]

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

 ID:   52317
 Updated by:   ahar...@php.net
 Reported by:  om at wysiwyg dot de
 Summary:  Segmentation fault when using mail() on a rhel 4.x
   (only 64 bit)
-Status:   Open
+Status:   Assigned
 Type: Bug
 Package:  Reproducible crash
 Operating System: rhel4.8_x86_64
 PHP Version:  5.2SVN-2010-07-12 (snap)
-Assigned To:  
+Assigned To:  aharvey

 New Comment:

Since I committed the offending patch, I'll look into it.



If you could provide both the test script (which doesn't seem to have
made it) and, if possible, a backtrace per the instructions [1], that
would be most helpful.



[1] http://bugs.php.net/bugs-generating-backtrace.php


Previous Comments:

[2010-07-12 16:52:53] om at wysiwyg dot de

Description:

Since the patch for headers_trimmed was added in the mail.c I always
get a segmentation fault when using mail(). This only affects rhel4.x 64
bit os. rhel 5.x 64 bit or rhel4.x 32 bit works fine.



Using mail.c from a snapshot before 2010-04-22 in the actual snapshot
source everything works fine.



--- php/php-src/branches/PHP_5_2/ext/standard/mail.c2010-04-22 01:07:48
UTC (rev 298290) - works fine

+++ php/php-src/branches/PHP_5_2/ext/standard/mail.c2010-04-22 02:22:49
UTC (rev 298291) - segmentation fault when using mail() in a php script
on a rhel4.x 64 bit host









Test script:
---
running make test after building php from source.



the provided test script also reports the problem.







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

Bug #52315 [Opn-Bgs]: Error in type convert after specific round() operation

[aharvey]

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

 ID:   52315
 Updated by:   ahar...@php.net
 Reported by:  wisent at yandex dot ru
 Summary:  Error in type convert after specific round() operation
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  Math related
 Operating System: Ubuntu 8.04
 PHP Version:  5.2.13

 New Comment:

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about floats and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.




Previous Comments:

[2010-07-12 14:40:58] wisent at yandex dot ru

Description:

First I perform specific round() operation. Then I convert the number
from float to integer. The result is wrong, the number differs by 1 from
what it should be.



The problem appears not for every number.

Test script:
---
// this works bad:

$sum = '4926.11';

$sum = round($sum, 2) * 100;

var_dump($sum);// float(492611)



$sum = (integer) $sum;

var_dump($sum);// int(492610)



// the same round() operation, the other number, works good

$sum = '426.11';

$sum = round($sum, 2) * 100;

var_dump($sum);// float(42611)



$sum = (integer) $sum;

var_dump($sum);// int(42611)



// the first numbers, the other round() operation, works good

$sum = '4926.11';

$sum = round($sum * 100);

var_dump($sum);// float(492611)



$sum = (integer) $sum;

var_dump($sum);// int(492611)













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

Bug #52330 [Opn-Wfx]: __construct() method should always return a new instance

[aharvey]

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

 ID:  52330
 Updated by:  ahar...@php.net
 Reported by: whistl0r+phpbug at googlemail dot com
 Summary: __construct() method should always return a new instance
-Status:  Open
+Status:  Wont fix
 Type:Bug
 Package: Class/Object related
 PHP Version: Irrelevant

 New Comment:

That might seem odd, but it seems consistent enough to me. It breaks
down one of two ways:



1. You call the constructor by instantiating an object with new. It
behaves like a constructor -- return values are ignored and a new object
instance is created.



2. You call the constructor by calling $object-__construct(). It
behaves like a method call, including return values being returned.



Basically, if you don't want __construct() to act like a method call,
don't call it like a method call.


Previous Comments:

[2010-07-13 16:35:38] whistl0r+phpbug at googlemail dot com

Description:

Please see the test script. This should be normal PHP 5.3 class with a
good OOP design.



In PHP it is possible, that I can call the constructor multiple times,
for example:



$person = new \My\Person('Jens', 'Mander');

echo sprintf('Name: %s %s', $person-getName(), $person-getSurname());
// Will output Name: Jens Mander



$person-__construct('John', 'Doe');

echo sprintf('Name: %s %s', $person-getName(), $person-getSurname());
// Will output Name: John Doe



In my understanding, it is unexpected, that

1) you can access the constructor method in an instantiated object. The
constructor should only instantiate the object - when you have the
object, there is no need to call it again. If you need something to
reset your object state, you should implement such a method.



2) If you can call the constructor again, that it will change the object
and *not* return a new instance.



For example:

If you add a return new \stdClass(); line to your constructor, it will
still change the instance you called it from, but now it will also
return a stdClass - that's inconsistent, isn't it?

Test script:
---
?php

namespace My;



class Person

{

  protected $_name = null;

  

  protected $_surname = null;

  

  /**

  * Constructor.

  * 

  * @param  string OPTIONAL $name

  * @param  string OPTIONAL $surname

  * @return \My\Person

  */

  public function __construct($name = null, $surname = null)

  {

if ($name !== null)

{

$this-setName($name);

}



if ($surname !== null)

{

$this-setSurname($surname);

}

  }

  

  /**

  * Returns the name.

  * 

  * @return null|string Null, when no name was set

  */

  public function getName()

  {

return $this-_name;

  }

  

  /**

  * Returns the surname.

  * 

  * @return null|string Null, when no name was set

  */

  public function getSurname()

  {

return $this-_surname;

  }

  

  /**

  * Set the name.

  * 

  * @param  string $name

  * @return \My\Person Provides fluent interface

  * @throws \Exception

  */

  public function setName($name)

  {

if (!is_string($name) || empty($name))

{

  throw new \Exception('Name cannot be empty and must be a
string!');

}



$this-_name = $name;





return $this;

  }

  

  /**

  * Set the surname.

  * 

  * @param string $name

  * @return \My\Person Provides fluent interface

  * @throws \Exception When $name isn't a string or empty

  */

  public function setSurname($name)

  {

if (!is_string($name) || empty($name))

{

  throw new \Exception('Name cannot be empty and must be a
string!');

}



$this-_surname = $name;





return $this;

  }

}

Expected result:

- FATAL error e.g. Object already constructed!



- The __construct() call should return a *new* object.

Actual result:
--
The __construct() method will work on the object, from where you called
it.






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

Bug #52311 [Opn-Bgs]: PHP raises Fatal Error on not existent method invocation

[aharvey]

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

 ID:   52311
 Updated by:   ahar...@php.net
 Reported by:  d dot orlando dot 0 at gmail dot com
 Summary:  PHP raises Fatal Error on not existent method
   invocation
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  *General Issues
 Operating System: Any
 PHP Version:  5.3.2

 New Comment:

This is by design, and can't be changed now without severely impacting
backward compatibility. Errors in PHP code don't generally raise
exceptions.


Previous Comments:

[2010-07-12 05:41:27] d dot orlando dot 0 at gmail dot com

Description:

Invoking a method that doesn't exist raises a Fatal Error, and there is
no way to 

catch the exception.

Test script:
---
?php



class A

{

public function __construct()

{

\error_reporting(\E_ALL);

\ini_set('display_errors', true);

\ini_set('display_startup_errors', true);



try { $this-_init(); } catch (\Exception $e) {echo
Catched!;}

}

}



new A();



Expected result:

Catched!

Actual result:
--
Fatal error: Call to undefined method A::_init() in 

/srv/http/PHP/3/fatalerror.php on line 11






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

Bug #52037 [Asn-Csd]: Concurrent builds fail in install-programs

[kalle]

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

 ID:   52037
 Updated by:   ka...@php.net
 Reported by:  seanius at debian dot org
 Summary:  Concurrent builds fail in install-programs
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  Compile Failure
 Operating System: Debian GNU/Linux
 PHP Version:  5.3.2
 Assigned To:  kalle

 New Comment:

This bug has been fixed in SVN.

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 fix will be included in the next RC's or be that final releases for
both 5.2 and 5.3


Previous Comments:

[2010-07-13 19:24:46] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=301244
Log: MFT: Fixed bug #52037 (Concurrent builds fail in install-programs)
-- Patch by Seanius at debian dot org

# Sorry for the non sparse commit, due to a broken co


[2010-07-13 19:24:16] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=301243
Log: MFT: Fixed bug #52037 (Concurrent builds fail in install-programs)
-- Patch by Seanius at debian dot org

# Sorry for the non sparse commit, due to a broken co


[2010-07-13 19:21:01] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=301242
Log: Fixed bug #52037 (Concurrent builds fail in install-programs) --
Patch by Seanius at debian dot org


[2010-07-01 18:07:19] seanius at debian dot org

hi,



yes, i believe so.  at least from a quick visual review it looks like it
has the same problem.


[2010-06-21 07:52:31] ka...@php.net

Does this apply to 5.2 aswell?




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/bug.php?id=52037


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

Bug #52330 [Wfx]: __construct() method should always return a new instance

[whistl0r+phpbug at googlemail dot com]

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

 ID:  52330
 User updated by: whistl0r+phpbug at googlemail dot com
 Reported by: whistl0r+phpbug at googlemail dot com
 Summary: __construct() method should always return a new
  instance
 Status:  Wont fix
 Type:Bug
 Package: Class/Object related
 PHP Version: Irrelevant

 New Comment:

 Basically, if you don't want __construct() to act like a method call,

 don't call it like a method call.



Well, why does PHP supports different visibilities like public,
protected or private? You can tell the programmer, don't read the
variable, it's private! like you say don't call it like a method. ;)



You support it, because it is part of the OOP concept (encapsulation).



Other languages like Java or C# doesn't allow you to call the
constructor like a method. The constructor is only callable with new
(because it's not a normal method).



Currently, to be safe from OOP view, it seems to me like you must add
something like



  protected $_initiated = false



to your class. If this is true, your constructor method will end. This
would make sure, that the constructor will only run once and you object
cannot enter an unexpected state, because someone calls the constructor
again...


Previous Comments:

[2010-07-13 18:34:08] ahar...@php.net

That might seem odd, but it seems consistent enough to me. It breaks
down one of two ways:



1. You call the constructor by instantiating an object with new. It
behaves like a constructor -- return values are ignored and a new object
instance is created.



2. You call the constructor by calling $object-__construct(). It
behaves like a method call, including return values being returned.



Basically, if you don't want __construct() to act like a method call,
don't call it like a method call.


[2010-07-13 16:35:38] whistl0r+phpbug at googlemail dot com

Description:

Please see the test script. This should be normal PHP 5.3 class with a
good OOP design.



In PHP it is possible, that I can call the constructor multiple times,
for example:



$person = new \My\Person('Jens', 'Mander');

echo sprintf('Name: %s %s', $person-getName(), $person-getSurname());
// Will output Name: Jens Mander



$person-__construct('John', 'Doe');

echo sprintf('Name: %s %s', $person-getName(), $person-getSurname());
// Will output Name: John Doe



In my understanding, it is unexpected, that

1) you can access the constructor method in an instantiated object. The
constructor should only instantiate the object - when you have the
object, there is no need to call it again. If you need something to
reset your object state, you should implement such a method.



2) If you can call the constructor again, that it will change the object
and *not* return a new instance.



For example:

If you add a return new \stdClass(); line to your constructor, it will
still change the instance you called it from, but now it will also
return a stdClass - that's inconsistent, isn't it?

Test script:
---
?php

namespace My;



class Person

{

  protected $_name = null;

  

  protected $_surname = null;

  

  /**

  * Constructor.

  * 

  * @param  string OPTIONAL $name

  * @param  string OPTIONAL $surname

  * @return \My\Person

  */

  public function __construct($name = null, $surname = null)

  {

if ($name !== null)

{

$this-setName($name);

}



if ($surname !== null)

{

$this-setSurname($surname);

}

  }

  

  /**

  * Returns the name.

  * 

  * @return null|string Null, when no name was set

  */

  public function getName()

  {

return $this-_name;

  }

  

  /**

  * Returns the surname.

  * 

  * @return null|string Null, when no name was set

  */

  public function getSurname()

  {

return $this-_surname;

  }

  

  /**

  * Set the name.

  * 

  * @param  string $name

  * @return \My\Person Provides fluent interface

  * @throws \Exception

  */

  public function setName($name)

  {

if (!is_string($name) || empty($name))

{

  throw new \Exception('Name cannot be empty and must be a
string!');

}



$this-_name = $name;





return $this;

  }

  

  /**

  * Set the surname.

  * 

  * @param string $name

  * @return \My\Person Provides fluent interface

  * @throws \Exception When $name isn't a string or empty

  */

  public function setSurname($name)

  {

if (!is_string($name) || empty($name))

{

  throw new \Exception('Name cannot be empty and must be a
string!');

}



$this-_surname = $name;





return $this;

  }

}

Expected result:

- FATAL error e.g. Object already constructed!



- The __construct() call should return a *new* object.

Req #12428 [Com]: I want 'echoln'

[php at guerrillamailblock dot com]

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

 ID:   12428
 Comment by:   php at guerrillamailblock dot com
 Reported by:  rvtol at xs4all dot nl
 Summary:  I want 'echoln'
 Status:   Closed
 Type: Feature/Change Request
 Package:  Feature/Change Request
 Operating System: any
 PHP Version:  4.0.6

 New Comment:

Why not?


Previous Comments:

[2002-04-27 15:50:40] j...@php.net

not going to happen.


[2001-07-27 11:04:33] rvtol at xs4all dot nl

Is there something like an 'echoln'? 



I use echo $var,'\n' quite often, 

so an 'echoln' would be very handy. 



Or even better would be macros:



#define echoln echo $, 'n'



Thanks, Ruud







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

Req #51440 [Com]: request extend echo print sentences

[php at guerrillamailblock dot com]

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

 ID:   51440
 Comment by:   php at guerrillamailblock dot com
 Reported by:  datamine dot maramirezc at gmail dot com
 Summary:  request extend echo print sentences
 Status:   Wont fix
 Type: Feature/Change Request
 Package:  Output Control
 Operating System: any
 PHP Version:  Irrelevant

 New Comment:

No, this is not Pascal, this is PHP. So what?


Previous Comments:

[2010-03-30 21:41:08] f...@php.net

This is not Pascal.


[2010-03-30 19:55:31] datamine dot maramirezc at gmail dot com

Description:

This is a request. 

Please, add iprintln/i and iecholn/i sentences.



Instead of writing this bseveral times/b:



pre

print whatever\n;

echo whatever\n;

/pre



We could use a more compact:



pre

println whatever;

echoln whatever;

/pre





It's useful when the program outputs a single string for a H.T.M.L.
single line.

This way, it's easier to debug the H.T.M.L. code generated.



Thanks.









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

Bug #52312 [Com]: PHP lstat problem

[v dot damore at gmail dot com]

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

 ID:   52312
 Comment by:   v dot damore at gmail dot com
 Reported by:  v dot damore at gmail dot com
 Summary:  PHP lstat problem
 Status:   Analyzed
 Type: Bug
 Package:  Safe Mode/open_basedir
 Operating System: Linux
 PHP Version:  5.2.13

 New Comment:

If you take a look at debugging done in
http://damore.xoom.it/apache-2.2_php-5.3.2_break-lstat.txt, you can see
that tsrm_realpath_r is called in 2 different place:



- First during phar_find_in_include_path function 

- Second during php_check_specific_open_basedir function.



* During php_check_specific_open_basedir, traverse entire path at least
three times, so i means 3 call to tsrm_realpath_r.



I don't discuss the need to traverse entire path, but only one time.



There should be a better way to implement such code, I'll try to write a
patch if there is someone that want help me looking what I'm writing.


Previous Comments:

[2010-07-13 15:23:33] paj...@php.net

The reason was due to a security flaw involving symbolic links and
realpath cache. It allowed to bypass open_basedir when a path was
cached. The cleanest way to fix it was to disable the realpath cache
when open_basedir/safemode are set.



Thanks Johannes to remind us about this change.


[2010-07-13 11:01:23] v dot damore at gmail dot com

Looking at source code main/main.c of 5.2.13 I can see:



1292:   /* Disable realpath cache if safe_mode or open_basedir are set 

*/

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1769:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



So realpath cache is definitely disabled in case of safe_mode or
open_basedir.

This dramatically reduce performance of PHP Engine and this behavior can
bring a 

server to its knees.

Especially because there is a lack of documentation!

Can you explain why this choose?

Must I continue debugging PHP engine in order to understand what's
happening?


[2010-07-13 01:52:37] v dot damore at gmail dot com

I found where the problem is, this behavior is not a bug.

Looking at main/main.c I found following lines:



1416:   /* Disable realpath cache if safe_mode or open_basedir
are set */

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1978:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



Could you explain why if safe_mode or open_basedir are set realpath
cache is disabled?


[2010-07-13 01:38:26] v dot damore at gmail dot com

There is a interesting update, I have found CWDG define so now we have:



(gdb) print cwd_globals.realpath_cache_size_limit

$3 = 0



Probably you should check why realpath_cache_size_limit is equal to 0


[2010-07-13 01:30:24] v dot damore at gmail dot com

After having set breakpoint tsrm_realpath_r and I have execute step by
step debug.

I think is interesting that after execution tsrm_virtual_cwd.c of line
681 execution continue on line 890.



gdb) break tsrm_realpath_r

Breakpoint 1 at 0x2b0b3c9f2702: file
/usr/local/sitipersonali/sitipersonali01/NSP_SERVICE/strillo/sources/php-5.3.2/TSRM/tsrm_virtual_cwd.c,
line 611.

(gdb) continue

Continuing.



Breakpoint 1, tsrm_realpath_r (path=0x7fffddfb32b0
/usr/local/myspace/webspace/httpdocs/test.php, start=1, len=45,
ll=0x7fffddfb32ac, t=0x7fffddfb32a0, use_realpath=2, is_dir=0,
link_is_dir=0x0)

at
/usr/local/sitipersonali/sitipersonali01/NSP_SERVICE/strillo/sources/php-5.3.2/TSRM/tsrm_virtual_cwd.c:611

611 int directory = 0;

(gdb) step

624 if (len = start) {

(gdb) step

628 i = len;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630 i--;

(gdb) step

629 while (i  start  !IS_SLASH(path[i-1])) {

(gdb) step

630   

Req #15211 [Com]: println?

[php at guerrillamailblock dot com]

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

 ID:  15211
 Comment by:  php at guerrillamailblock dot com
 Reported by: dark_panda at hushmail dot com
 Summary: println?
 Status:  Bogus
 Type:Feature/Change Request
 Package: Feature/Change Request
 PHP Version: 4.1.1

 New Comment:

ugly:

echo hello world\n;# bad practice to use double quotes
everywhere

echo 'hello world', \n;# why do I have to write , \n?

echo 'hello world', PHP_EOL; # oh boy



nice:

echoln 'hello world';



Same thing goes for println.


Previous Comments:

[2003-02-06 21:08:28] il...@php.net

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. 

Thank you for your interest in PHP.

Given the number of print functions already in PHP this seem pointless,
especially considering it'd only print a single character.


[2002-06-08 10:38:26] bigredlinux at yahoo dot com

Actually, what would be HUGE is if println could determine the sapi
module it is running as and then add the endline appropriately, meaning
for the web it would add a 'br clear=all /' tag after the line.



But honestly, if php is really going to be considered for commandline
scripting, it needs a println() feature.


[2002-01-24 13:36:56] dark_panda at hushmail dot com

I'm in the midst of doing quite a bit of shell/command line 

stuff with PHP, and I think it would be kind of useful to 

have a println construct, much like in Java or a number of 

other languages. println is identical to print, but a 

newline/carriage return is appended to the output. 



I know I could just write function in PHP or even a 

function in an extension to provide the same functionality, 

but it might as well be in the language itself, if only 

because it may be used often enough to warrant inclusion. 

(I know I'd use it all the time.) 



I started trying to add it myself (I can see that it would 

go in the Zend engine, correct?) but after reminding myself 

that I've never used Lex before (nor really looked at the 

Zend code) I decided that this would be best left to 

someone who actually knows what they're doing when it 

comes to the Zend engine.



The only problem I can think of is portability, 

specifically the oft-cursed differences between OS newline 

sequences. (Is it \n? \r\n? \n\r? Dammit?!) Doesn't seem 

like a huge issue, though, does it?



J







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

Bug #52312 [Com]: PHP lstat problem

[v dot damore at gmail dot com]

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

 ID:   52312
 Comment by:   v dot damore at gmail dot com
 Reported by:  v dot damore at gmail dot com
 Summary:  PHP lstat problem
 Status:   Analyzed
 Type: Bug
 Package:  Safe Mode/open_basedir
 Operating System: Linux
 PHP Version:  5.2.13

 New Comment:

Please pay attention correct URL for debugging info is 

http://damore.xoom.it/apache-2.2_php-5.3.2_break-lstat.txt


Previous Comments:

[2010-07-13 21:04:24] v dot damore at gmail dot com

If you take a look at debugging done in
http://damore.xoom.it/apache-2.2_php-5.3.2_break-lstat.txt, you can see
that tsrm_realpath_r is called in 2 different place:



- First during phar_find_in_include_path function 

- Second during php_check_specific_open_basedir function.



* During php_check_specific_open_basedir, traverse entire path at least
three times, so i means 3 call to tsrm_realpath_r.



I don't discuss the need to traverse entire path, but only one time.



There should be a better way to implement such code, I'll try to write a
patch if there is someone that want help me looking what I'm writing.


[2010-07-13 15:23:33] paj...@php.net

The reason was due to a security flaw involving symbolic links and
realpath cache. It allowed to bypass open_basedir when a path was
cached. The cleanest way to fix it was to disable the realpath cache
when open_basedir/safemode are set.



Thanks Johannes to remind us about this change.


[2010-07-13 11:01:23] v dot damore at gmail dot com

Looking at source code main/main.c of 5.2.13 I can see:



1292:   /* Disable realpath cache if safe_mode or open_basedir are set 

*/

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1769:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



So realpath cache is definitely disabled in case of safe_mode or
open_basedir.

This dramatically reduce performance of PHP Engine and this behavior can
bring a 

server to its knees.

Especially because there is a lack of documentation!

Can you explain why this choose?

Must I continue debugging PHP engine in order to understand what's
happening?


[2010-07-13 01:52:37] v dot damore at gmail dot com

I found where the problem is, this behavior is not a bug.

Looking at main/main.c I found following lines:



1416:   /* Disable realpath cache if safe_mode or open_basedir
are set */

if (PG(safe_mode) || (PG(open_basedir) 
*PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



1978:   /* Disable realpath cache if safe_mode or open_basedir are set */

if (PG(safe_mode) || (PG(open_basedir)  *PG(open_basedir))) {

CWDG(realpath_cache_size_limit) = 0;

}



Could you explain why if safe_mode or open_basedir are set realpath
cache is disabled?


[2010-07-13 01:38:26] v dot damore at gmail dot com

There is a interesting update, I have found CWDG define so now we have:



(gdb) print cwd_globals.realpath_cache_size_limit

$3 = 0



Probably you should check why realpath_cache_size_limit is equal to 0




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/bug.php?id=52312


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

Bug #51216 [Opn-Fbk]: Segmentation fault when compiling PHP with PHAR

[srinatar]

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

 ID:   51216
 Updated by:   srina...@php.net
 Reported by:  dtm2mcs at gmail dot com
 Summary:  Segmentation fault when compiling PHP with PHAR
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  PHAR related
 Operating System: Ubuntu 6.04 + CentOS 5.4
 PHP Version:  5.3.2

 New Comment:

please see if this issue can be reproduced with php 5.3.3 (RC2)-
http://qa.php.net/ 



and if yes, please provide us a stack trace as mentioned here. 

http://bugs.php.net/bugs-generating-backtrace.php


Previous Comments:

[2010-07-08 17:00:24] bluefox012 at gmail dot com

centos 5.4

have the same problem,



[activating module `php5' in /home/services/web/config/httpd.conf]

Installing PHP CLI binary:/usr/local/php/bin/

Installing PHP CLI man page:  /usr/local/php/man/man1/

Installing build environment: /usr/local/php/lib/php/build/

Installing header files:  /usr/local/php/include/php/

Installing helper programs:   /usr/local/php/bin/

  program: phpize

  program: php-config

Installing man pages: /usr/local/php/man/man1/

  page: phpize.1

  page: php-config.1

Installing PEAR environment:  /usr/local/php/lib/php/

make[1]: *** [install-pear-installer] Segmentation fault

make: *** [install-pear] Error 2


[2010-05-08 00:54:01] leonard dot f dot elia at nasa dot gov

So, I tried compiling without phar:



./configure --prefix=/usr/local/php532-dist \

--with-curl=/usr/local --enable-exif --with-gd \

--with-nsapi=/usr/local/iplanet7 \

--with-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-mysqli=/usr/local/mysql/bin/mysql_config \

--with-oci8=instantclient,/usr/local/oracle \

--with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-pdo-oci=/usr/local/oracle \

--with-jpeg-dir=/usr/local --with-png-dir=/usr/local \

--enable-libgcc \

--disable-phar



The make now completes as expected but make install now throws up:



[r...@allegro php5]# make install

Installing PHP SAPI module:   nsapi

Installing PHP CLI binary:/usr/local/php532-dist/bin/

Installing PHP CLI man page:  /usr/local/php532-dist/man/man1/

Installing build environment: /usr/local/php532-dist/lib/php/build/

Installing header files:  /usr/local/php532-dist/include/php/

Installing helper programs:   /usr/local/php532-dist/bin/

  program: phpize

  program: php-config

Installing man pages: /usr/local/php532-dist/man/man1/

  page: phpize.1

  page: php-config.1

Installing PEAR environment:  /usr/local/php532-dist/lib/php/

Segmentation Fault

make[1]: *** [install-pear-installer] Error 139

make: *** [install-pear] Error 2



And this bug, my friends, isn't in the bug database (that I have
found).



Any ideas?



My system has a working php in the path (5.3.1) and is up to date on
patches etc.


[2010-05-07 23:52:55] leonard dot f dot elia at nasa dot gov

Almost forgot, I am building php 5.3.2 as a NSAPI module for iPlanet 7
using mysql 5.1.40



./configure --prefix=/usr/local/php532-dist \

--with-curl=/usr/local --enable-exif --with-gd \

--with-nsapi=/usr/local/iplanet7 \

--with-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-mysqli=/usr/local/mysql/bin/mysql_config \

--with-oci8=instantclient,/usr/local/oracle \

--with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-pdo-oci=/usr/local/oracle \

--with-jpeg-dir=/usr/local --with-png-dir=/usr/local \

--enable-libgcc



thank you


[2010-05-07 23:50:26] leonard dot f dot elia at nasa dot gov

I am getting this bug with



gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

GNU Make 3.81  built for sparc-sun-solaris2.10

SunOS xxx 5.10 Generic_142900-01 sun4u sparc SUNW,Sun-Fire-480R
Solaris

Memory: 1024M phys mem, 608M free mem, 2048M total swap, 2018M free
swap



Any workarounds are gratefully appreciated


[2010-04-22 10:24:02] ywliu at hotmail dot com

I can confirm this one: 



1. On CentOS 5.4



2. Apache Worker MPM.



3. With mysqlnd, it wouldn't trigger segfault. But with external mysql
library (my own build of 5.0.81) , it segfaults.



So looks like maybe it's the combination of worker MPM with the external
mysql library.



ywliu




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/bug.php?id=51216


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

Bug #48669 [Com]: PHP now includes GOTO

[risto78 at gmail dot com]

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

 ID:   48669
 Comment by:   risto78 at gmail dot com
 Reported by:  iwannalive at hotmail dot com
 Summary:  PHP now includes GOTO
 Status:   Bogus
 Type: Bug
 Package:  Reproducible crash
 Operating System: All
 PHP Version:  5.3.0RC4

 New Comment:

sounds like a valid bug to me ;)


Previous Comments:

[2010-05-07 14:41:11] anil at ozselgin dot com

It makes php more buggy and suitable only for small programs. Is there
anybody out there like readable code.


[2009-08-04 18:47:50] and...@php.net

goto hell;


[2009-06-23 23:56:29] der...@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

.


[2009-06-23 23:46:57] iwannalive at hotmail dot com

Description:

PHP 5.3 includes goto. This is a problem. Seriously, PHP has made it
this far without goto, why turn the language into a public menace?

Reproduce code:
---
?php

goto a;

echo 'Foo';

 

a:

echo 'Bar';

?



Expected result:

The world will end.

Actual result:
--
The world ended.






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

Bug #51943 [Asn-Csd]: Several files are out of ANSI spec

[kalle]

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

 ID:   51943
 Updated by:   ka...@php.net
 Reported by:  CoreyStup at gmail dot com
 Summary:  Several files are out of ANSI spec
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  Compile Failure
 Operating System: AIX
 PHP Version:  5.2.13
 Assigned To:  kalle

 New Comment:

This bug has been fixed in SVN.

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.

Fixed in the latest RC for both 5.2 and 5.3


Previous Comments:

[2010-07-14 02:04:45] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=301253
Log: Update the re2c files aswell (bug #51943)


[2010-07-14 01:59:56] ka...@php.net

Automatic comment from SVN on behalf of kalle
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=301252
Log: Fixed bug #51943 (Several files are out of ANSI spec)

# Based on patch by CoreyStup at gmail dot com


[2010-06-21 07:49:30] ka...@php.net

The parse_date.c one is quite easy too, its just a matter of:



#ifndef _AIX

typedef ...

#endif



Since parse_date.c also defines uchar to unsigned char, im assigning
this bug to myself and see if i can get my sparse co working and ill
commit this


[2010-05-28 17:08:09] CoreyStup at gmail dot com

Description:

Using a native compiler on AIX, several files are not ANSI compliant and
won't compile.



ext/pdo/php_pdo_driver.h, trailing commas are not allowed in enums.



ext/hash/php_hash_tiger.h, bitfields must be defined as type int,
unsigned int, 

or signed int.   char is not allowed.



ext/date/lib/parse_date.c, uchar already defined conflict. I'm not sure
what the correct fix is.  AIX already has uchar defined in sys/types.h:

/usr/include/sys/types.h:typedefunsigned char   uchar_t;

/usr/include/sys/types.h:typedefuchar_t uchar;















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

[PHP-BUG] Bug #52332 [NEW]: Static Member Reference Not Updating

[kolb0057 at umn dot edu]

From: 
Operating system: Windows XP Home SP3
PHP version:  5.2.13
Package:  Class/Object related
Bug Type: Bug
Bug description:Static Member Reference Not Updating

Description:

When an object's member is assigned as a reference to a different class'
static member and that static member is itself later assigned by reference,
the original object member's reference is not being updated.





I posted this question to the PHP General Mailing List.  One user confirmed
the bug for V5.0.0 to V5.3.3RC2.  In case you would like to search the
archive, the subject of the email was Static Class Member References.

Test script:
---
?php

class A

{

  public static $a = 3;

}



class B 

{

public $b;



public function assign()

{

$this-b = A::$a;

}

}



$b = new B;

$a = new A;

$b-assign();

A::$a = $a;



var_dump($b-b); // expected: object(A) | result: int 3

?

Expected result:

I expect 'var_dump($b-b);'  to print: object(A).

Actual result:
--
'var_dump($b-b);' is actually printing 'int 3'.

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

Bug #52332 [Opn]: Static Member Reference Not Updating

[kolb0057 at umn dot edu]

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

 ID:   52332
 User updated by:  kolb0057 at umn dot edu
 Reported by:  kolb0057 at umn dot edu
 Summary:  Static Member Reference Not Updating
 Status:   Open
 Type: Bug
 Package:  Class/Object related
 Operating System: Windows XP Home SP3
 PHP Version:  5.2.13

 New Comment:

Thank you.


Previous Comments:

[2010-07-14 03:13:00] kolb0057 at umn dot edu

Description:

When an object's member is assigned as a reference to a different class'
static member and that static member is itself later assigned by
reference, the original object member's reference is not being updated.





I posted this question to the PHP General Mailing List.  One user
confirmed the bug for V5.0.0 to V5.3.3RC2.  In case you would like to
search the archive, the subject of the email was Static Class Member
References.

Test script:
---
?php

class A

{

  public static $a = 3;

}



class B 

{

public $b;



public function assign()

{

$this-b = A::$a;

}

}



$b = new B;

$a = new A;

$b-assign();

A::$a = $a;



var_dump($b-b); // expected: object(A) | result: int 3

?

Expected result:

I expect 'var_dump($b-b);'  to print: object(A).

Actual result:
--
'var_dump($b-b);' is actually printing 'int 3'.






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

Bug #39485 [NoF-Fbk]: mkdir() fails when pathname have space(s) on the final

[felipe]

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

 ID:   39485
 Updated by:   fel...@php.net
 Reported by:  v1d4l0k4 at gmail dot com
 Summary:  mkdir() fails when pathname have space(s) on the final
-Status:   No Feedback
+Status:   Feedback
 Type: Bug
 Package:  *Directory/Filesystem functions
 Operating System: Windows XP (Win32 only)
 PHP Version:  5.2.0

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2006-11-29 01:00:00] 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.


[2006-11-21 21:03:31] tony2...@php.net

Cannot reproduce:



C:\php -r var_dump(mkdir('dirname '));

bool(true)




[2006-11-13 04:29:24] v1d4l0k4 at gmail dot com

Description:

The 'mkdir' function doesn't function correctly on Windows when the
pathname contain space(s) on the final. PHP returns a warning, and the
directory isn't created:



Warning: mkdir() [function.mkdir]: Invalid argument in X on line Y



Temporary fix: use trim() on the pathname



Besides, if the pathname contain space(s) on the start, the directory is
created when couldn't even so (in accordance with the behavior of
Windows Explorer).

Reproduce code:
---
?php



mkdir('pathname ');

mkdir(' pathname');



?

Expected result:

?php



mkdir('pathname '); // Succeeds, but trim() before, in accordance with
the behavior of Windows Explorer

mkdir(' pathname'); // Succeeds, but trim() before, in accordance with
the behavior of Windows Explorer



?

Actual result:
--
?php



mkdir('pathname '); // Fails

mkdir(' pathname'); // Succeeds even not being recommended



?






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

Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR

[ywliu at hotmail dot com]

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

 ID:   51216
 Comment by:   ywliu at hotmail dot com
 Reported by:  dtm2mcs at gmail dot com
 Summary:  Segmentation fault when compiling PHP with PHAR
 Status:   Feedback
 Type: Bug
 Package:  PHAR related
 Operating System: Ubuntu 6.04 + CentOS 5.4
 PHP Version:  5.3.2

 New Comment:

Just tried 5.3.3RC2. This problem on the latest CentOS 5.5 is gone.


Previous Comments:

[2010-07-13 23:01:20] srina...@php.net

please see if this issue can be reproduced with php 5.3.3 (RC2)-
http://qa.php.net/ 



and if yes, please provide us a stack trace as mentioned here. 

http://bugs.php.net/bugs-generating-backtrace.php


[2010-07-08 17:00:24] bluefox012 at gmail dot com

centos 5.4

have the same problem,



[activating module `php5' in /home/services/web/config/httpd.conf]

Installing PHP CLI binary:/usr/local/php/bin/

Installing PHP CLI man page:  /usr/local/php/man/man1/

Installing build environment: /usr/local/php/lib/php/build/

Installing header files:  /usr/local/php/include/php/

Installing helper programs:   /usr/local/php/bin/

  program: phpize

  program: php-config

Installing man pages: /usr/local/php/man/man1/

  page: phpize.1

  page: php-config.1

Installing PEAR environment:  /usr/local/php/lib/php/

make[1]: *** [install-pear-installer] Segmentation fault

make: *** [install-pear] Error 2


[2010-05-08 00:54:01] leonard dot f dot elia at nasa dot gov

So, I tried compiling without phar:



./configure --prefix=/usr/local/php532-dist \

--with-curl=/usr/local --enable-exif --with-gd \

--with-nsapi=/usr/local/iplanet7 \

--with-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-mysqli=/usr/local/mysql/bin/mysql_config \

--with-oci8=instantclient,/usr/local/oracle \

--with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-pdo-oci=/usr/local/oracle \

--with-jpeg-dir=/usr/local --with-png-dir=/usr/local \

--enable-libgcc \

--disable-phar



The make now completes as expected but make install now throws up:



[r...@allegro php5]# make install

Installing PHP SAPI module:   nsapi

Installing PHP CLI binary:/usr/local/php532-dist/bin/

Installing PHP CLI man page:  /usr/local/php532-dist/man/man1/

Installing build environment: /usr/local/php532-dist/lib/php/build/

Installing header files:  /usr/local/php532-dist/include/php/

Installing helper programs:   /usr/local/php532-dist/bin/

  program: phpize

  program: php-config

Installing man pages: /usr/local/php532-dist/man/man1/

  page: phpize.1

  page: php-config.1

Installing PEAR environment:  /usr/local/php532-dist/lib/php/

Segmentation Fault

make[1]: *** [install-pear-installer] Error 139

make: *** [install-pear] Error 2



And this bug, my friends, isn't in the bug database (that I have
found).



Any ideas?



My system has a working php in the path (5.3.1) and is up to date on
patches etc.


[2010-05-07 23:52:55] leonard dot f dot elia at nasa dot gov

Almost forgot, I am building php 5.3.2 as a NSAPI module for iPlanet 7
using mysql 5.1.40



./configure --prefix=/usr/local/php532-dist \

--with-curl=/usr/local --enable-exif --with-gd \

--with-nsapi=/usr/local/iplanet7 \

--with-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-mysqli=/usr/local/mysql/bin/mysql_config \

--with-oci8=instantclient,/usr/local/oracle \

--with-pdo-mysql=/usr/local/mysql-client/mysql-5.1.40 \

--with-pdo-oci=/usr/local/oracle \

--with-jpeg-dir=/usr/local --with-png-dir=/usr/local \

--enable-libgcc



thank you


[2010-05-07 23:50:26] leonard dot f dot elia at nasa dot gov

I am getting this bug with



gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

GNU Make 3.81  built for sparc-sun-solaris2.10

SunOS xxx 5.10 Generic_142900-01 sun4u sparc SUNW,Sun-Fire-480R
Solaris

Memory: 1024M phys mem, 608M free mem, 2048M total swap, 2018M free
swap



Any workarounds are gratefully appreciated




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/bug.php?id=51216


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

[PHP-BUG] Bug #52333 [NEW]: Metacharacter \d in a regexp causes an error on some Russian letters

[a dot dobkin at drweb dot com]

From: 
Operating system: Windows
PHP version:  5.3.2
Package:  *Regular Expressions
Bug Type: Bug
Bug description:Metacharacter \d in a regexp causes an error on some Russian 
letters

Description:

Metacharacter \d in a regular expression causes an error on some Russian
letters 

on OS Windows. 



Example script:



$user_name_ru = Василий;

$regexp = /[\d...@\#\%\$\^*\(\)\~\=\/\|\\'\?\:\;\/]+/;

if( preg_match( $regexp,$user_name_ru ) ) {

 echo 'ERR';

} else {

 echo 'OK';

}



preg_match() return true if word contains one or more characters 'й',
'г', 'в'. 

If to delete metacharacter '\d' preg_match() returns false.   If you are
using 

php version 5.2.13 all works correctly.


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

Bug #52333 [Opn]: Metacharacter \d in a regexp causes an error on some Russian letters

[a dot dobkin at drweb dot com]

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

 ID:   52333
 User updated by:  a dot dobkin at drweb dot com
 Reported by:  a dot dobkin at drweb dot com
 Summary:  Metacharacter \d in a regexp causes an error on some
   Russian letters
 Status:   Open
 Type: Bug
 Package:  *Regular Expressions
 Operating System: Windows
 PHP Version:  5.3.2

 New Comment:

OS 2003 Server R2 SP2 English x86


Previous Comments:

[2010-07-14 07:03:15] a dot dobkin at drweb dot com

Description:

Metacharacter \d in a regular expression causes an error on some Russian
letters 

on OS Windows. 



Example script:



$user_name_ru = Василий;

$regexp = /[\d...@\#\%\$\^*\(\)\~\=\/\|\\'\?\:\;\/]+/;

if( preg_match( $regexp,$user_name_ru ) ) {

 echo 'ERR';

} else {

 echo 'OK';

}



preg_match() return true if word contains one or more characters 'й',
'г', 'в'. 

If to delete metacharacter '\d' preg_match() returns false.   If you are
using 

php version 5.2.13 all works correctly.







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