[PHP-BUG] Req #64054 [NEW]: Alternative syntax to access, replace, count a portion of a string or an array

2013-01-23 Thread reptilien dot 19831209be1 at gmail dot com 
From: reptilien dot 19831209be1 at gmail dot com
Operating system: 
PHP version:  Irrelevant
Package:  Output Control
Bug Type: Feature/Change Request
Bug description:Alternative syntax to access, replace, count a portion of a 
string or an array

Description:

This is a simply and intuitive proposition to access or replace a part of a

string or an array. This syntax from partly shell script syntax. We can
extend 
this proposition for a simply way to count the number of characteres of a
string 
or elements of an array.

Test script:
---
$str = abcdefghi;
$arr = array(j, k, l, m, n);
$arr1= array(j, k, array(l, m), n, o);

Expected result:

---
Propositions :
---

1. Alternative to substr
$str[0:5] // return 'abcde'
$str[:5] // return 'abcde' (the same as above)
$str[0:-1] // the same as $str
$str[1:2] // return 'bc'
$str[-2] // return 'hi'
$str[-3:1] // return 'g'

2. Alternative to substr_replace
$str[0:5]=jklmn; // $str is now 'jklmnfghi'
$str[:5]=jklmn; // $str is now 'jklmnfghi' (the same as above)
$str[-5]=j; // $str is now 'abcdjfghi'
$str[-5]=jklmn; // $str is now 'abcdjklmn'
$str[-5]=jklmnopqr; // $str is now 'abcdjklmn', the rest is ignored

3. Alternative to array_slice()
$arr[0:4] // return 'j', 'k', 'l', 'm'
$arr[:4] // return 'j', 'k', 'l', 'm' (the same as above)
$arr[0:-1] // the same as $arr
$arr[-2] // return 'm', 'n' (if key -2 doesn't exist)
$arr[-2:2] // force to return 'm', 'n' (without ambiguation)
$arr[-3:1] // return 'l'
$arr1[2:2] // return ('l', 'm'), 'n'
$arr1[2:2][0] // return ('l', 'm')
$arr1[2:2][1] // return 'n'

4. Alternative to array_replace()
$arr[0:4]=array('a', 'b', 'c', 'd'); // $arr is now  'a', 'b', 'c', 'd',
'n'
$arr[-2]=array('a', 'b'); // $arr is now  'j', 'k', 'l', 'a', 'b' (if key
-2 
doesn't exist)
$arr[-2:2]=array('a', 'b'); // $arr is now  'j', 'k', 'l', 'a', 'b' (forced

method, without ambiguation)
$arr1[-3:2]=array(array('x', 'y'), 'z'); // $arr1 is now 'j', 'k', ('x',
'y'), 
'z', 'o'
$arr1[-3:2]=array(array('x', 'y'), 'z', 'a'); // $arr1 is now 'j', 'k',
('x', 
'y'), 'z', 'o' (the rest is ignored)

5. Alternative to strlen() and count()
note: in shell script, # is used to count the number of chararacters in a 
string; in php # is used for comments (we need an other symbol)
$str[#] // musn't be used
$str[?] // return 9
$arr[?] // return 5
$arr[1:-1:?] // return 4 (equivalent at count($arr)-1)

Actual result:
--
---
Actual results :
---
$str[0]; // return a
$arr[0]; // return j
$arr1[2]; // return ('l', 'm')

$str[0]=x; // $str is now xbcdefghi
$str[3]=xyz; // $str is now 'abcxefghi' // the rest 'yz' is ignored
$arr[-1]=x; // $arr is now 'j', 'k', 'l', 'm', 'n', -1='x'

---
Actual errors/warnings :
---
$str[-1] // PHP Warning:  Illegal string offset:  -1 (should return 'i')
$arr[-1] // PHP Notice:  Undefined offset: -1 (should return 'n' if key -1

doesn't exist)
$arr[-1:1] // PHP Parse error:  syntax error, unexpected ':', expecting ']'

(should return 'n', none ambiguation)

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

Bug #64052 [Opn-Nab]: PHP DateTime Add and sub

2013-01-23 Thread derick 
Edit report at https://bugs.php.net/bug.php?id=64052edit=1

 ID: 64052
 Updated by: der...@php.net
 Reported by:moses dot liao at techlinkz dot net
 Summary:PHP DateTime Add and sub
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Date/time related
 Operating System:   Linux
 PHP Version:5.3.21
 Block user comment: N
 Private report: N

 New Comment:

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

Thank you for your interest in PHP.

This has been filed so many times, and it's still not a bug. For a full 
explanation, see: http://derickrethans.nl/obtaining-the-next-month-in-php.html


Previous Comments:

[2013-01-23 03:07:22] moses dot liao at techlinkz dot net

Description:

Using the current datetime, adding and subtracting one month does not result in 
an actual one month addition and subtraction

Test script:
---
td valign=top
?php

$previousMonth = new DateTime ('2013-03-31');
$previousMonth-sub (new DateInterval ('P1M'));
echo $previousMonth-format ('Y-m-d');

?
/td

td valign=top
?php

$nextMonth = new DateTime ('2013-03-31');
$nextMonth-add (new DateInterval ('P1M'));
echo $nextMonth-format ('Y-m-d');

?
/td


Expected result:

previous month to show 2013-02-*, next month to show 2013-04-*

Actual result:
--
td2013-03-03/tdtd2013-05-01/td






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

[PHP-BUG] Bug #64055 [NEW]: nextRowset() returns false

2013-01-23 Thread kenji dot uui at gmail dot com 
From: kenji dot uui at gmail dot com
Operating system: Ubuntu
PHP version:  5.3.21
Package:  PDO related
Bug Type: Bug
Bug description:nextRowset() returns false

Description:

The below code expects 3 result sets, but only 2 returned.


Test script:
---
?php

$db = new PDO('mysql:host=localhost;dbname=information_schema', 'root',
'');
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$sql = SQL
SELECT * FROM CHARACTER_SETS WHERE CHARACTER_SET_NAME = 'sjis';
SELECT * FROM CHARACTER_SETS WHERE CHARACTER_SET_NAME = 'utf8';
SELECT * FROM CHARACTER_SETS WHERE CHARACTER_SET_NAME = 'ujis';
SQL;
$result = $db-query($sql);
$i = 1;
do {
  echo br /;
  echo Result set , $i++, :\n; 
  print_r($result-fetchAll());
} while ($result-nextRowset());


Expected result:

Result set 1: Array ( [0] = Array ( [CHARACTER_SET_NAME] = sjis [0] =
sjis [DEFAULT_COLLATE_NAME] = sjis_japanese_ci [1] = sjis_japanese_ci
[DESCRIPTION] = Shift-JIS Japanese [2] = Shift-JIS Japanese [MAXLEN] = 2
[3] = 2 ) )
Result set 2: Array ( [0] = Array ( [CHARACTER_SET_NAME] = utf8 [0] =
utf8 [DEFAULT_COLLATE_NAME] = utf8_general_ci [1] = utf8_general_ci
[DESCRIPTION] = UTF-8 Unicode [2] = UTF-8 Unicode [MAXLEN] = 3 [3] = 3
) )
Result set 3: Array ( [0] = Array ( [CHARACTER_SET_NAME] = ujis [0] =
ujis [DEFAULT_COLLATE_NAME] = ujis_japanese_ci [1] = ujis_japanese_ci
[DESCRIPTION] = EUC-JP Japanese [2] = EUC-JP Japanese [MAXLEN] = 3 [3]
= 3 ) ) 

Actual result:
--
Result set 1: Array ( [0] = Array ( [CHARACTER_SET_NAME] = sjis [0] =
sjis [DEFAULT_COLLATE_NAME] = sjis_japanese_ci [1] = sjis_japanese_ci
[DESCRIPTION] = Shift-JIS Japanese [2] = Shift-JIS Japanese [MAXLEN] = 2
[3] = 2 ) )
Result set 2: Array ( [0] = Array ( [CHARACTER_SET_NAME] = utf8 [0] =
utf8 [DEFAULT_COLLATE_NAME] = utf8_general_ci [1] = utf8_general_ci
[DESCRIPTION] = UTF-8 Unicode [2] = UTF-8 Unicode [MAXLEN] = 3 [3] = 3
) ) 

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

Bug #63780 [Com]: Segmentation fault when try to get $request

2013-01-23 Thread saschaprolic at googlemail dot com 
Edit report at https://bugs.php.net/bug.php?id=63780edit=1

 ID: 63780
 Comment by: saschaprolic at googlemail dot com
 Reported by:php dot maks3w at virtualplanets dot net
 Summary:Segmentation fault when try to get $request
 Status: Feedback
 Type:   Bug
 Package:SOAP related
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

I experienced the same bug. You can find my strace log at: 
https://gist.github.com/4604494


Previous Comments:

[2012-12-16 11:17:29] re...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.




[2012-12-15 18:06:17] php dot maks3w at virtualplanets dot net

Description:

Situation: Custom class which extend from SoapClient and override public 
function __doRequest($request, $location, $action, $version, $one_way = null)

$request can't be used to compare strings, instead throw a Segmentation Fault 
error.

$request looks like a C Pointer or any other type instead of a PHP String type

As workaround you can filter the variable passing the value through a function 
which return basically the same value of the argument passed as input (like 
ltrim) after that it's possible save the returned value and now is a normal PHP 
String and can be compared.

Test script:
---
FAILING CODE:
public $lastRequest;

function __doRequest($request, $location, $action, $version, $one_way = 0) {
$this-lastRequest = $request;
}

$this-assertEquals('SomeContent', $this-lastRequest); // Segmentation Faul.


WORKAROUND:
public $lastRequest;

function __doRequest($request, $location, $action, $version, $one_way = 0) {
$this-lastRequest = ltrim($request); // Pass $request through a function
}

$this-assertEquals('SomeContent', $this-lastRequest); // Works








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

Bug #49664 [Com]: Clone causes Segmentation fault

2013-01-23 Thread cf0hay at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=49664edit=1

 ID: 49664
 Comment by: cf0hay at gmail dot com
 Reported by:patrik dot lermon at gmail dot com
 Summary:Clone causes Segmentation fault
 Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.*, 6 (2009-09-20)
 Block user comment: N
 Private report: N

 New Comment:

 Infinite recursion crashes. There's no fix for that.

Err, what?

$ php -r 'function a(){ a(); } a();'
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to 
allocate 130968 bytes) in Command line code on line 1

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to 
allocate 
130968 bytes) in Command line code on line 1

This is the intended behaviour on infinite recursion, not a segmentation fault. 
I wouldn't be surprised this could lead a security problem rather just a simple 
crash.


Previous Comments:

[2012-12-18 23:53:05] kurt at kurtrose dot com

Python handles this kind of recursion fine:

class F(object):
   def __repr__(self): return self.__repr__()

 repr(F())
  File stdin, line 2, in __repr__
  File stdin, line 2, in __repr__
  ...
  File stdin, line 2, in __repr__
  File stdin, line 2, in __repr__
RuntimeError: maximum recursion depth exceeded

No segfault.


[2009-10-19 15:31:17] patrik dot lermon at gmail dot com

I don't agree. Perhaps my knowledge is not detailed enough, but an infinte 
recursion should:
a) run out of memory and die, or
b) detect the recursion and die.
In both these cases PHP should die in a controlled manner, not segfault.

My understanding is that segfault is never ok - that means the code is faulty.


[2009-10-19 15:10:24] j...@php.net

Infinite recursion crashes. There's no fix for that.


[2009-09-28 12:06:43] patrik dot lermon at gmail dot com

I get the same result with http://snaps.php.net/php5.3-latest.tar.gz
on Slackware.


[2009-09-25 07:50:31] patrik dot lermon at gmail dot com

I am aware that the cloning will be recursive in some circumstances, but PHP 
should not segfault because of this.




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

https://bugs.php.net/bug.php?id=49664


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

Bug #64053 [Opn-Nab]: It's possible to change constant value in C extension.

2013-01-23 Thread johannes 
Edit report at https://bugs.php.net/bug.php?id=64053edit=1

 ID: 64053
 Updated by: johan...@php.net
 Reported by:gasol dot wu at gmail dot com
 Summary:It's possible to change constant value in C
 extension.
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   MacOS X 10.8/FreeBSD 9.1
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

PHP extensions can do many things. What you are doing is changing engine-owned 
memory. Anything might happen. Make sure to either separate the zval of the 
parameter or copy the string before modifying it.


Previous Comments:

[2013-01-23 06:05:36] gasol dot wu at gmail dot com

Description:

I have encounter this problem couple weeks ago, So I write some tests to see 
different result between PHP 5.3 and PHP 5.4 (even in 5.4.11).

https://github.com/Gasol/const_test

Testing Result:

5.4.11
=
PHP : /Users/gasol/.phpbrew/php/php-5.4.11/bin/php 
PHP_SAPI: cli
PHP_VERSION : 5.4.11
ZEND_VERSION: 2.4.0
PHP_OS  : Darwin - Darwin gasol-mbp 12.2.0 Darwin Kernel Version 12.2.0: 
Sat 
Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
INI actual  : /Users/gasol/Code/const_test/tmp-php.ini
More .INIs  :  
CWD : /Users/gasol/Code/const_test
Extra dirs  : 
VALGRIND: Not used
=
TIME START 2013-01-23 05:52:33
=
PASS Check for const_test presence [tests/001-load.phpt] 
FAIL Check for modify custom constant [tests/002-modify_const.phpt] 
PASS Check for modify constant declared in class [tests/003-
modify_class_const.phpt] 
FAIL Check for modify system constant [tests/004-modify_system_const.phpt] 
=
TIME END 2013-01-23 05:52:33

PHP 5.3.21
=
PHP : /Users/gasol/.phpbrew/php/php-5.3.21/bin/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.21
ZEND_VERSION: 2.3.0
PHP_OS  : Darwin - Darwin gasol-mbp 12.2.0 Darwin Kernel Version 12.2.0: 
Sat 
Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
INI actual  : /Users/gasol/Code/const_test/tmp-php.ini
More .INIs  :  
CWD : /Users/gasol/Code/const_test
Extra dirs  : 
VALGRIND: Not used
=
TIME START 2013-01-23 06:03:06
=
PASS Check for const_test presence [tests/001-load.phpt] 
PASS Check for modify custom constant [tests/002-modify_const.phpt] 
PASS Check for modify constant declared in class [tests/003-
modify_class_const.phpt] 
PASS Check for modify system constant [tests/004-modify_system_const.phpt] 
=
TIME END 2013-01-23 06:03:06







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

Bug #49664 [Com]: Clone causes Segmentation fault

2013-01-23 Thread patrik dot lermon at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=49664edit=1

 ID: 49664
 Comment by: patrik dot lermon at gmail dot com
 Reported by:patrik dot lermon at gmail dot com
 Summary:Clone causes Segmentation fault
 Status: Not a bug
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.*, 6 (2009-09-20)
 Block user comment: N
 Private report: N

 New Comment:

And what do you get when you try with the reproduce code?


Previous Comments:

[2013-01-23 11:27:55] cf0hay at gmail dot com

 Infinite recursion crashes. There's no fix for that.

Err, what?

$ php -r 'function a(){ a(); } a();'
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to 
allocate 130968 bytes) in Command line code on line 1

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to 
allocate 
130968 bytes) in Command line code on line 1

This is the intended behaviour on infinite recursion, not a segmentation fault. 
I wouldn't be surprised this could lead a security problem rather just a simple 
crash.


[2012-12-18 23:53:05] kurt at kurtrose dot com

Python handles this kind of recursion fine:

class F(object):
   def __repr__(self): return self.__repr__()

 repr(F())
  File stdin, line 2, in __repr__
  File stdin, line 2, in __repr__
  ...
  File stdin, line 2, in __repr__
  File stdin, line 2, in __repr__
RuntimeError: maximum recursion depth exceeded

No segfault.


[2009-10-19 15:31:17] patrik dot lermon at gmail dot com

I don't agree. Perhaps my knowledge is not detailed enough, but an infinte 
recursion should:
a) run out of memory and die, or
b) detect the recursion and die.
In both these cases PHP should die in a controlled manner, not segfault.

My understanding is that segfault is never ok - that means the code is faulty.


[2009-10-19 15:10:24] j...@php.net

Infinite recursion crashes. There's no fix for that.


[2009-09-28 12:06:43] patrik dot lermon at gmail dot com

I get the same result with http://snaps.php.net/php5.3-latest.tar.gz
on Slackware.




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

https://bugs.php.net/bug.php?id=49664


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

Bug #61551 [Com]: Error /usr/bin/ld: warning: libnnz11.so not found when using --disable-rpath

2013-01-23 Thread kenji dot uui at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61551edit=1

 ID: 61551
 Comment by: kenji dot uui at gmail dot com
 Reported by:jm at trash-mail dot com
 Summary:Error /usr/bin/ld: warning: libnnz11.so not found
 when using --disable-rpath
 Status: Assigned
 Type:   Bug
 Package:OCI8 related
 Operating System:   linux x64
 PHP Version:Irrelevant
 Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

Your patch worked fine. I built php-5.3.21.


Previous Comments:

[2013-01-22 07:16:39] s...@php.net

Try the attached patch to ext/oci8/config.m4.
Rebuild the configuration file before configuring the PHP build:
  ./buildconf --force
  ./configure ...
  make


[2013-01-22 07:14:36] s...@php.net

The following patch has been added/updated:

Patch Name: config.m4.61551.patch
Revision:   1358838876
URL:
https://bugs.php.net/patch-display.php?bug=61551patch=config.m4.61551.patchrevision=1358838876


[2013-01-22 05:02:47] s...@php.net

Either:
- Don't use --disable-rpath.
- set LD_LIBRARY_PATH to the Oracle library directory before invoking 'make'.


[2013-01-18 10:18:08] kenji dot uui at gmail dot com

I got the error when I built php-5.3.20:

/usr/bin/ld: warning: libnnz11.so, needed by 
/u01/app/oracle/product/11.2.0/xe/lib/libclntsh.so, not found (try using -rpath 
or -rpath-link)

configure:

'./configure' '--build=x86_64-redhat-linux-gnu' 
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' 
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' 
'--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' 
'--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' 
'--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--cache-file=../config.cache' 
'--with-libdir=lib64' '--with-config-file-path=/etc' 
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' 
'--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' 
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' 
'--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' 
'--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pcre-regex=/usr' 
'--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' 
'--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' 
'--enable-sysvshm' '--enable-sysvmsg' '--with-kerberos' 
'--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--enable-xml' 
'--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--disable-dom' 
'--disable-dba' '--without-unixODBC' '--enable-pdo' '--disable-xmlreader' 
'--disable-xmlwriter' '--without-sqlite3' '--disable-phar' '--disable-fileinfo' 
'--disable-json' '--without-pspell' '--disable-wddx' '--without-curl' 
'--disable-posix' '--disable-sysvmsg' '--disable-sysvshm' '--disable-sysvsem' 
--with-oci8 --with-pdo-oci=$ORACLE_HOME --with-sqlite3 --enable-sqlite-utf8

Environment:

CentOS 5.2 64bit
oracle-xe-11.2.0-1.0.x86_64.rpm
PHP 5.3.20


[2012-03-29 15:05:56] s...@php.net

What operating system and version are you using?
What version of Instant Client are you using?
What is your 'configure' line?




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

https://bugs.php.net/bug.php?id=61551


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

Bug #64023 [Ver-Csd]: Overloading __toString() in SplFileInfo has no effect

2013-01-23 Thread cataphract 
Edit report at https://bugs.php.net/bug.php?id=64023edit=1

 ID: 64023
 Updated by: cataphr...@php.net
 Reported by:php at lightning dot hu
 Summary:Overloading __toString() in SplFileInfo has no
 effect
-Status: Verified
+Status: Closed
 Type:   Bug
 Package:SPL related
 Operating System:   Linux
 PHP Version:Irrelevant
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of glo...@nebm.ist.utl.pt
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=aa0adce47d9b8ead59efede63a769e395e27bcd5
Log: Fix bug #64023 (__toString() amp; SplFileInfo)


Previous Comments:

[2013-01-19 15:54:43] cataphr...@php.net

Fix: https://github.com/cataphract/php-src/compare/bug64023


[2013-01-18 15:24:39] php at lightning dot hu

Description:

When I overload the __toString() magic method in the SplFileInfo class or in 
one 
of it's derivatives it does not work if I concatenate the object with a string.
See the example for a simple demonstration.

Test script:
---
class A extends \SplFileInfo
{
public function __toString() {return ' -expected- ';}
}

$a = new A('/');

// Works
echo $a, $a-__toString(), $a-__toString() . '';

// Does not work - outputs parent::__toString()
echo $a . '';

Expected result:

-expected-  -expected-  -expected- /







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

[PHP-BUG] Req #64056 [NEW]: array_rand returns differ - should always be an array

2013-01-23 Thread joern dot berkefeld at bittubes dot com 
From: joern dot berkefeld at bittubes dot com
Operating system: -
PHP version:  Irrelevant
Package:  *General Issues
Bug Type: Feature/Change Request
Bug description:array_rand returns differ - should always be an array

Description:

---
From manual page: http://www.php.net/function.array-rand
---

From the manual:
If you are picking only one entry, array_rand() returns the key for a
random 
entry. Otherwise, it returns an array of keys for the random entries

That causes problems as this functionality is unexpected. Functions should
always 
return the same type (or false / null for failure)

Expected result:

get an array regardless of the number of results

Actual result:
--
the function returns an integer for one result and an array for multiple
results

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

Req #64056 [Opn-Wfx]: array_rand returns differ - should always be an array

2013-01-23 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=64056edit=1

 ID: 64056
 Updated by: paj...@php.net
 Reported by:joern dot berkefeld at bittubes dot com
 Summary:array_rand returns differ - should always be an
 array
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   -
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

We can't change that due to backward compatibility reason.


Previous Comments:

[2013-01-23 14:57:37] joern dot berkefeld at bittubes dot com

Description:

---
From manual page: http://www.php.net/function.array-rand
---

From the manual:
If you are picking only one entry, array_rand() returns the key for a random 
entry. Otherwise, it returns an array of keys for the random entries

That causes problems as this functionality is unexpected. Functions should 
always 
return the same type (or false / null for failure)

Expected result:

get an array regardless of the number of results

Actual result:
--
the function returns an integer for one result and an array for multiple results






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

Bug #63740 [Opn]: strtotime seems to use both sunday and monday as start of week

2013-01-23 Thread googleguy 
Edit report at https://bugs.php.net/bug.php?id=63740edit=1

 ID: 63740
 Updated by: google...@php.net
 Reported by:salmanarshad2000 at yahoo dot com
 Summary:strtotime seems to use both sunday and monday as
 start of week
 Status: Open
 Type:   Bug
 Package:Date/time related
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

I've actually recently updated the documentation about strtotime in regard to 
this very 
behavior. See Bug #52143.

The problem is that prior to PHP 5.3.0 the relative time formats this week, 
next week, 
previous week were taken to mean a 7 day period relative to the current time. 
However, 
the behavior was changed in PHP 5.3.0 to be interpreted as a week period of 
Monday 
through Sunday. This is noted in the documentation for strtotime in the 
changelog section 
since last week.

http://php.net/manual/en/function.strtotime.php#refsect1-function.strtotime-changelog

We can see this behavior more clearly from the following code...


var_dump(date(D Y-m-d, strtotime(this week, strtotime(2012-12-08;
string(14) Mon 2012-12-03

var_dump(date(D Y-m-d, strtotime(this week, strtotime(2012-12-09;
string(14) Mon 2012-12-10


Here what you'll notice is that this week always starts on a Monday. Now, 
when you want 
make that format relative to a particular day of the week, let's say Sunday...

var_dump(date(D Y-m-d, strtotime(Sunday this week, 
strtotime(2012-12-08;
string(14) Sun 2012-12-09

var_dump(date(D Y-m-d, strtotime(Sunday this week, 
strtotime(2012-12-09;
string(14) Sun 2012-12-16


What you should notice is that this week is first normalized to Mon 
2012-12-03 and 
Mon 2012-12-10, respectively. Then the day is moved up to the first Sunday 
of that 
week (i.e. +6 days on each week).

This might sounds a little confusing because if you are expecting the week to 
begin on a 
Sunday and end on a Saturday then you would assume that Sunday this week 
would mean 
2012-12-09 where the date is 2012-12-09 and the day is a Sunday. But that's 
not the 
case. this week means Monday of the current week and then move up until the 
very next 
Sunday. So if today is Sunday, we don't get today's date when we try Sunday 
this week.


Previous Comments:

[2012-12-11 15:18:40] salmanarshad2000 at yahoo dot com

Description:

Weeks start on Sunday or Monday. However, in this regard:

1) strtotime behavior is not documented.
2) strtotime produces inconsistent results when this week is used.

Sample dates from month of December 2012 used the the test script:

Mon 2012-12-03
Tue 2012-12-04
Wed 2012-12-05
Thu 2012-12-06
Fri 2012-12-07
Sat 2012-12-08
Sun 2012-12-09
Mon 2012-12-10
Tue 2012-12-11
Wed 2012-12-12
Thu 2012-12-13
Fri 2012-12-14
Sat 2012-12-15
Sun 2012-12-16


Test script:
---
// function strtotime called on Sun 2012-12-09
echo date(D Y-m-d, strtotime(monday this week, strtotime(2012-12-09))); 
// Mon 2012-12-10
echo date(D Y-m-d, strtotime(sunday this week, strtotime(2012-12-09))); 
// Sun 2012-12-16

// function strtotime called on Mon 2012-12-10
echo date(D Y-m-d, strtotime(monday this week, strtotime(2012-12-10))); 
// Mon 2012-12-10
echo date(D Y-m-d, strtotime(sunday this week, strtotime(2012-12-10))); 
// Sun 2012-12-16


Expected result:

If Sunday is start of the week then sunday this week be less than monday 
this week:

// function strtotime called on Sun 2012-12-09
echo date(D Y-m-d, strtotime(monday this week, strtotime(2012-12-09))); 
// Mon 2012-12-10
echo date(D Y-m-d, strtotime(sunday this week, strtotime(2012-12-09))); 
// Sun 2012-12-09

// function strtotime called on Mon 2012-12-10
echo date(D Y-m-d, strtotime(monday this week, strtotime(2012-12-10))); 
// Mon 2012-12-10
echo date(D Y-m-d, strtotime(sunday this week, strtotime(2012-12-10))); 
// Sun 2012-12-09

If Monday is start of the week then monday this week should return different 
values on sunday and monday:

// function strtotime called on Sun 2012-12-09
echo date(D Y-m-d, strtotime(monday this week, strtotime(2012-12-09))); 
// Mon 2012-12-03
echo date(D Y-m-d, strtotime(sunday this week, strtotime(2012-12-09))); 
// Sun 2012-12-09

// function strtotime called on Mon 2012-12-10
echo date(D Y-m-d, strtotime(monday this week, strtotime(2012-12-10))); 
// Mon 2012-12-10
echo date(D Y-m-d, strtotime(sunday this week, strtotime(2012-12-10))); 
// Sun 2012-12-16

Actual result:
--
See test script, actual result is present alongside each line.






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

Bug #52424 [Com]: Function naming inconsistency: htmlentities() x html_entity_decode()

2013-01-23 Thread lenton64 at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=52424edit=1

 ID: 52424
 Comment by: lenton64 at gmail dot com
 Reported by:php-bugs at majkl578 dot cz
 Summary:Function naming inconsistency: htmlentities() x
 html_entity_decode()
 Status: Wont fix
 Type:   Bug
 Package:Unknown/Other Function
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

I feel that this is a big problem in PHP. It makes it super hard to remember 
function names (especially for newcomers) with these inconsistencies and gives 
PHP an ugly syntax reputation.

Please change all function names to:
words_separated_with_underscore()

and then alias the original functions to the new ones.

It may take a long time for everyone to change the functions in their 
applications but you can keep them aliased for however long everyone needs.

This naming convention needs to become a standard in PHP at some point, why not 
get the ball rolling now.


Previous Comments:

[2010-07-29 02:09:38] ras...@php.net

We don't mind change, but our users really really don't like it when we break 
their working applications for cosmetic reasons.


[2010-07-29 02:05:31] php-bugs at majkl578 dot cz

Yes and that is what I think should change, because current naming conventions 
are really horrible. For instance, look at differences between str_replace, 
strlen, parse_str, htmlspecialchars. All work with same type but their names 
are completely different.
So, string functions should go to String namespace (String\replace()), array 
functions to Array namespace (Array\search()) and so on.

But unfortunately this will not happen because PHP does not like changes... 
Think about it.


[2010-07-25 00:19:32] giorgio dot liscio at email dot it

php functions uses a lot of different syntax

isset
is_array
isPublic

but aliasing is evil and renaming is not appreciated by users... the best thing 
you can do is implement your renamed function in your namespace

bye


[2010-07-24 07:11:06] php-bugs at majkl578 dot cz

Description:

I suggest adding a function htmlentities_decode() as a replacement for 
html_entity_decode() and possibly deprecate that one.
It is really misleading and unintuitive because there are functions 
htmlspecialchars() and htmlspecialchars_decode() doing similar thing.







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

Req #42516 [Com]: __FILE__ resolves symlinks

2013-01-23 Thread ale dot comp_06 at xox dot ch 
Edit report at https://bugs.php.net/bug.php?id=42516edit=1

 ID: 42516
 Comment by: ale dot comp_06 at xox dot ch
 Reported by:michael at zedeler dot dk
 Summary:__FILE__ resolves symlinks
 Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:4.4.7
 Block user comment: N
 Private report: N

 New Comment:

On development server I often have symlinked directories to common libraries.

It would be wonderful to have an option for the behavior of __FILE__ and allow 
it to return the non resolved path if the developer wishes so.

Generally speaking, having some paths automatically resolved and some not, is 
very disturbing. As far I can tell, all paths should be unresolved and one 
should use resolve_path() to get the real path. A central switch should 
allow to get all the paths resolved if one wants so (or the other way: the 
default being the paths being resolved and the switch makes them unresolved).


Previous Comments:

[2012-06-15 07:43:47] daniele dot segato at gmail dot com

This bug was open since 2007

would you mind assigning it to someone for fixing or discuss why you are 
leaving 
it open?
maybe someone out there can help you

thank you


[2012-04-06 17:28:55] bj...@php.net

I don't know why this was assigned to me


[2011-08-20 09:56:33] clicky at erebot dot net

Also, the DOCUMENT_ROOT workaround only works in case you're dealing with a 
website. It's completely useless in case you're working from a terminal (eg. 
some unit tests run through PHPUnit).

+1 on having this behaviour changed (maybe as a second magic constant as other 
proposed, so as not to break backward compatibility for __FILE__).


[2011-07-20 05:23:46] mpok at xs4all dot nl

@Tyra3l: the problem most people (including myself) are having is that 
$_SERVER[SCRIPT_FILENAME] contains the path to the file that was called, not 
the path to the file that is actually processed. This means you can't use 
$_SERVER[SCRIPT_FILENAME] as a replacement for __FILE__; in fact there is no 
way to get a non-resolved path to the current script.

Example:
Website calls [DOCUMENT_ROOT]/index.php
Cronjob calls [DOCUMENT_ROOT]/lib/cron/maintenance.php

Both files include [DOCUMENT_ROOT]/lib/config/startup.php

Now the startup.php script has to set path variables/constants to use 
throughout 
the framework. If you use __FILE__ for this it will return the path to the 
settings.php script, regardless of whether it was included/called from the 
website (index.php) or the cronjob (maintenance.php). This allows you to 
reliably set paths relative to the location of settings.php.

However if you symlink the /lib/ directory __FILE__ will resolve the symlinked 
path and thus break for setting the framework paths relative to the website.

Using $_SERVER[SCRIPT_FILENAME] in startup.php will result in different paths 
depending on which file was called. When called from the website it returns 
[DOCUMENT_ROOT]/index.php, when called from the cronjob it returns 
[DOCUMENT_ROOT]/lib/cron/maintenance.php. This means that if you want to make 
sure you get a reliable path to the lib inside the website you'd have to write 
a 
bunch of additional code with semi-intelligent matching in order to find a 
specific path, if at all possible. Another option is to set the base path 
seperately in each file that is an entry point for the framework so that those 
files define their existence relative to the lib dir. This does create more 
dependencies though.

All in all it would be far better if there was an option in the php.ini to 
disable symlink resolving for __FILE__ (and subsequently __DIR__). If I want to 
resolve symlinks I'd use realpath() anyway.


[2011-04-13 09:32:46] tyra3l at gmail dot com

$_SERVER[SCRIPT_FILENAME] can be used for getting the non-resolved path, and 
the 
documentation at 
http://php.net/manual/en/language.constants.predefined.php
now contains info about __FILE__ is resolved to absolute path with resolved 
symlinks.
so I think that this could be closed.

Tyrael




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

https://bugs.php.net/bug.php?id=42516


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

[PHP-BUG] Bug #64057 [NEW]: substr_replace failed charset utf-8

2013-01-23 Thread ltsujiguchi at gmail dot com 
From: ltsujiguchi at gmail dot com
Operating system: Ubuntu 12.10
PHP version:  5.4.11
Package:  Strings related
Bug Type: Bug
Bug description:substr_replace failed charset utf-8

Description:

I had a problem when i used the substr_replace, using those changes os
php.ini:

I couldn't find the exact version of my php on the drop, so i put the
closest 
version, but my real version is the 5.4.6.

Result expected:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE %é%

Result returned:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE%é%?

Test script:
---
$replacement = '%é%';
$cond = 'noticia.noticia_titulo LIKE ? OR noticia.noticia_conteudo LIKE
?';
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
echo $cond;


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

Bug #64053 [Com]: It's possible to change constant value in C extension.

2013-01-23 Thread gasol dot wu at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=64053edit=1

 ID: 64053
 Comment by: gasol dot wu at gmail dot com
 Reported by:gasol dot wu at gmail dot com
 Summary:It's possible to change constant value in C
 extension.
 Status: Not a bug
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   MacOS X 10.8/FreeBSD 9.1
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

I understand PHP extensions can do many things, But why does PHP 5.3 and PHP 
5.4 
have inconsistent result ?


Previous Comments:

[2013-01-23 11:50:33] johan...@php.net

PHP extensions can do many things. What you are doing is changing engine-owned 
memory. Anything might happen. Make sure to either separate the zval of the 
parameter or copy the string before modifying it.


[2013-01-23 06:05:36] gasol dot wu at gmail dot com

Description:

I have encounter this problem couple weeks ago, So I write some tests to see 
different result between PHP 5.3 and PHP 5.4 (even in 5.4.11).

https://github.com/Gasol/const_test

Testing Result:

5.4.11
=
PHP : /Users/gasol/.phpbrew/php/php-5.4.11/bin/php 
PHP_SAPI: cli
PHP_VERSION : 5.4.11
ZEND_VERSION: 2.4.0
PHP_OS  : Darwin - Darwin gasol-mbp 12.2.0 Darwin Kernel Version 12.2.0: 
Sat 
Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
INI actual  : /Users/gasol/Code/const_test/tmp-php.ini
More .INIs  :  
CWD : /Users/gasol/Code/const_test
Extra dirs  : 
VALGRIND: Not used
=
TIME START 2013-01-23 05:52:33
=
PASS Check for const_test presence [tests/001-load.phpt] 
FAIL Check for modify custom constant [tests/002-modify_const.phpt] 
PASS Check for modify constant declared in class [tests/003-
modify_class_const.phpt] 
FAIL Check for modify system constant [tests/004-modify_system_const.phpt] 
=
TIME END 2013-01-23 05:52:33

PHP 5.3.21
=
PHP : /Users/gasol/.phpbrew/php/php-5.3.21/bin/php 
PHP_SAPI: cli
PHP_VERSION : 5.3.21
ZEND_VERSION: 2.3.0
PHP_OS  : Darwin - Darwin gasol-mbp 12.2.0 Darwin Kernel Version 12.2.0: 
Sat 
Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
INI actual  : /Users/gasol/Code/const_test/tmp-php.ini
More .INIs  :  
CWD : /Users/gasol/Code/const_test
Extra dirs  : 
VALGRIND: Not used
=
TIME START 2013-01-23 06:03:06
=
PASS Check for const_test presence [tests/001-load.phpt] 
PASS Check for modify custom constant [tests/002-modify_const.phpt] 
PASS Check for modify constant declared in class [tests/003-
modify_class_const.phpt] 
PASS Check for modify system constant [tests/004-modify_system_const.phpt] 
=
TIME END 2013-01-23 06:03:06







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

Bug #64046 [Com]: Segmentation fault in pcre library

2013-01-23 Thread krak...@php.net 
Edit report at https://bugs.php.net/bug.php?id=64046edit=1

 ID: 64046
 Comment by: krak...@php.net
 Reported by:public at miholeus dot com
 Summary:Segmentation fault in pcre library
 Status: Open
 Type:   Bug
 Package:PCRE related
 Operating System:   Ubuntu 12.04.1 LTS
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

This does cause a stack overflow, for some reason the default limits for 
recursion are very high, maybe someone has an explanation of that.

You have:
/'([^'])*'/

Shouldn't that be:
/'([^']*)'/

?


Previous Comments:

[2013-01-22 13:47:19] public at miholeus dot com

Description:

The following code causes segmentation fault. You can see the code by link I've 
provided.

Test script:
---
Code http://pastebin.com/UzBjDaZU

Expected result:

no segfault

Actual result:
--
With gdb:

(gdb) run /var/www/work/crm/trunk/pcre.php
Starting program: /usr/bin/php /var/www/work/crm/trunk/pcre.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x7fffe42e4700 (LWP 4329)]
[Thread 0x7fffe42e4700 (LWP 4329) exited]

Program received signal SIGSEGV, Segmentation fault.
0x76d99a62 in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3






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

Bug #64057 [Opn]: substr_replace failed charset utf-8

2013-01-23 Thread krakjoe 
Edit report at https://bugs.php.net/bug.php?id=64057edit=1

 ID: 64057
 Updated by: krak...@php.net
 Reported by:ltsujiguchi at gmail dot com
 Summary:substr_replace failed charset utf-8
 Status: Open
 Type:   Bug
 Package:Strings related
 Operating System:   Ubuntu 12.10
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

[joe@fiji php-5.4.6]$ nano 64057.php
[joe@fiji php-5.4.6]$ sapi/cli/php 64057.php
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE %é%

Anyone else ??


Previous Comments:

[2013-01-23 17:54:21] ltsujiguchi at gmail dot com

Description:

I had a problem when i used the substr_replace, using those changes os php.ini:

I couldn't find the exact version of my php on the drop, so i put the closest 
version, but my real version is the 5.4.6.

Result expected:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE %é%

Result returned:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE%é%?

Test script:
---
$replacement = '%é%';
$cond = 'noticia.noticia_titulo LIKE ? OR noticia.noticia_conteudo LIKE ?';
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
echo $cond;







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

Req #42516 [Opn-Nab]: __FILE__ resolves symlinks

2013-01-23 Thread pajoye 
Edit report at https://bugs.php.net/bug.php?id=42516edit=1

 ID: 42516
 Updated by: paj...@php.net
 Reported by:michael at zedeler dot dk
 Summary:__FILE__ resolves symlinks
-Status: Open
+Status: Not a bug
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:4.4.7
 Block user comment: N
 Private report: N

 New Comment:

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

It is required by require_once and include_once, along other things (realpath 
cache). It always been like that.


Previous Comments:

[2013-01-23 17:36:39] ale dot comp_06 at xox dot ch

On development server I often have symlinked directories to common libraries.

It would be wonderful to have an option for the behavior of __FILE__ and allow 
it to return the non resolved path if the developer wishes so.

Generally speaking, having some paths automatically resolved and some not, is 
very disturbing. As far I can tell, all paths should be unresolved and one 
should use resolve_path() to get the real path. A central switch should 
allow to get all the paths resolved if one wants so (or the other way: the 
default being the paths being resolved and the switch makes them unresolved).


[2012-06-15 07:43:47] daniele dot segato at gmail dot com

This bug was open since 2007

would you mind assigning it to someone for fixing or discuss why you are 
leaving 
it open?
maybe someone out there can help you

thank you


[2012-04-06 17:28:55] bj...@php.net

I don't know why this was assigned to me


[2011-08-20 09:56:33] clicky at erebot dot net

Also, the DOCUMENT_ROOT workaround only works in case you're dealing with a 
website. It's completely useless in case you're working from a terminal (eg. 
some unit tests run through PHPUnit).

+1 on having this behaviour changed (maybe as a second magic constant as other 
proposed, so as not to break backward compatibility for __FILE__).


[2011-07-20 05:23:46] mpok at xs4all dot nl

@Tyra3l: the problem most people (including myself) are having is that 
$_SERVER[SCRIPT_FILENAME] contains the path to the file that was called, not 
the path to the file that is actually processed. This means you can't use 
$_SERVER[SCRIPT_FILENAME] as a replacement for __FILE__; in fact there is no 
way to get a non-resolved path to the current script.

Example:
Website calls [DOCUMENT_ROOT]/index.php
Cronjob calls [DOCUMENT_ROOT]/lib/cron/maintenance.php

Both files include [DOCUMENT_ROOT]/lib/config/startup.php

Now the startup.php script has to set path variables/constants to use 
throughout 
the framework. If you use __FILE__ for this it will return the path to the 
settings.php script, regardless of whether it was included/called from the 
website (index.php) or the cronjob (maintenance.php). This allows you to 
reliably set paths relative to the location of settings.php.

However if you symlink the /lib/ directory __FILE__ will resolve the symlinked 
path and thus break for setting the framework paths relative to the website.

Using $_SERVER[SCRIPT_FILENAME] in startup.php will result in different paths 
depending on which file was called. When called from the website it returns 
[DOCUMENT_ROOT]/index.php, when called from the cronjob it returns 
[DOCUMENT_ROOT]/lib/cron/maintenance.php. This means that if you want to make 
sure you get a reliable path to the lib inside the website you'd have to write 
a 
bunch of additional code with semi-intelligent matching in order to find a 
specific path, if at all possible. Another option is to set the base path 
seperately in each file that is an entry point for the framework so that those 
files define their existence relative to the lib dir. This does create more 
dependencies though.

All in all it would be far better if there was an option in the php.ini to 
disable symlink resolving for __FILE__ (and subsequently __DIR__). If I want to 
resolve symlinks I'd use realpath() anyway.




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

https://bugs.php.net/bug.php?id=42516


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

Bug #62004 [Com]: SplFileObject: fgets after seek returns wrong line

2013-01-23 Thread sebak_pl1 at gazeta dot pl 
Edit report at https://bugs.php.net/bug.php?id=62004edit=1

 ID: 62004
 Comment by: sebak_pl1 at gazeta dot pl
 Reported by:don dot binda at verizon dot net
 Summary:SplFileObject: fgets after seek returns wrong line
 Status: Open
 Type:   Bug
 Package:SPL related
 Operating System:   Windows Server 2003
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Same for me. PHP v5.4.11


Previous Comments:

[2012-06-03 20:47:26] carloschilazo at gmail dot com

Based on documentation, it says that fgets Returns:

Returns a string containing the NEXT line from the file

wouldn't that explain?


[2012-05-17 14:35:16] don dot binda at verizon dot net

Fixing version


[2012-05-11 13:59:04] don dot binda at verizon dot net

Description:

This is occurring in 5.4.0, although 5.4.x isn't an option under version.

Appears to be related to (or same as) 46569:

Calling fgets() after seek() to any non-zero line returns one line later than 
expected. seek(0) works fine and calling current() instead of fgets() also 
works correctly.

Test script:
---
Source file (temp.txt):
Line 1
Line 2
Line 3
Line 4

Code:
$f = new SplFileObject('temp.txt');
$f-seek(0);
echo $f-fgets();
$f-seek(1);
echo $f-fgets();
$f-seek(2);
echo $f-fgets();

Expected result:

Line 1
Line 2
Line 3

Actual result:
--
Line 1
Line 3
Line 4






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

Bug #64057 [Com]: substr_replace failed charset utf-8

2013-01-23 Thread mail+php at requinix dot net 
Edit report at https://bugs.php.net/bug.php?id=64057edit=1

 ID: 64057
 Comment by: mail+php at requinix dot net
 Reported by:ltsujiguchi at gmail dot com
 Summary:substr_replace failed charset utf-8
 Status: Open
 Type:   Bug
 Package:Strings related
 Operating System:   Ubuntu 12.10
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

Do you have one of those weird editors where shift+space produces something 
besides a regular space? It may sound stupid and probably won't change anything 
but try deleting the LIKE ? and typing it again carefully.

Also stupid and pointless, check that
  echo bin2hex($cond);
ends in ...4c494b45203f.


Previous Comments:

[2013-01-23 18:21:39] krak...@php.net

[joe@fiji php-5.4.6]$ nano 64057.php
[joe@fiji php-5.4.6]$ sapi/cli/php 64057.php
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE %é%

Anyone else ??


[2013-01-23 17:54:21] ltsujiguchi at gmail dot com

Description:

I had a problem when i used the substr_replace, using those changes os php.ini:

I couldn't find the exact version of my php on the drop, so i put the closest 
version, but my real version is the 5.4.6.

Result expected:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE %é%

Result returned:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE%é%?

Test script:
---
$replacement = '%é%';
$cond = 'noticia.noticia_titulo LIKE ? OR noticia.noticia_conteudo LIKE ?';
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
echo $cond;







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

[PHP-BUG] Bug #64060 [NEW]: Test lstat_stat_variation7 incorrectly fails on certain file systems

2013-01-23 Thread m dot voelker at gmail dot com 
From: m dot voelker at gmail dot com
Operating system: Linux
PHP version:  5.4.11
Package:  Testing related
Bug Type: Bug
Bug description:Test lstat_stat_variation7 incorrectly fails on certain file 
systems

Description:

This applies to PHP 5.4.11 as well as 5.3.21.

Test ext/standard/tests/file/lstat_stat_variation7.phpt may incorrectly
fail on delayed allocation file systems (in this case XFS on Linux).

Problem:
http://php.net/manual/en/function.stat.php
field 12 is number of 512-byte blocks allocated

The test does not fclose() the test file after writing to it, therefore
zero 512-byte blocks are allocated even though the file size is 45056
bytes.

Fix:
Change lstat_stat_variation7.phpt from

// writing to an empty file
echo *** Testing stat() on file after data is written in it ***\n;
$fh = fopen($file_name,w);
$old_stat = stat($file_name);
clearstatcache();
fwrite($fh, str_repeat((binary)Hello World, $old_stat['blksize']));
$new_stat = stat($file_name);

to

// writing to an empty file
echo *** Testing stat() on file after data is written in it ***\n;
$fh = fopen($file_name,w);
$old_stat = stat($file_name);
clearstatcache();
fwrite($fh, str_repeat((binary)Hello World, $old_stat['blksize']));
fclose($fh);
$new_stat = stat($file_name);

and the test succeeds.


Test script:
---
File: ext/standard/tests/file/lstat_stat_variation7.php

To confirm, modify $file_name = $file_path/lstat_stat_variation7.tmp; to
use a different file system and run
ext/standard/tests/file/lstat_stat_variation7.sh.


Expected result:

Build of PHP 5.4.11

Test executed on ext2:

*** Testing stat() on file after data is written in it ***
bool(true)
bool(true)
bool(true)

--- Done ---


Actual result:
--
Same test executed on XFS:

*** Testing stat() on file after data is written in it ***
bool(true)
bool(true)
Error: stat1 is not lesser than stat2 at key value: 12
Error: stat1 is not lesser than stat2 at key value: blocks

 Dumping stat array 1...
...

  [size]=
  int(0)
...
  [blocks]=
  int(0)

 Dumping stat array 2...
...
  [size]=
  int(45056)
...
  [blocks]=
  int(0)


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

Bug #52424 [Com]: Function naming inconsistency: htmlentities() x html_entity_decode()

2013-01-23 Thread php at lavoie dot sl 
Edit report at https://bugs.php.net/bug.php?id=52424edit=1

 ID: 52424
 Comment by: php at lavoie dot sl
 Reported by:php-bugs at majkl578 dot cz
 Summary:Function naming inconsistency: htmlentities() x
 html_entity_decode()
 Status: Wont fix
 Type:   Bug
 Package:Unknown/Other Function
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

The core functions’ naming is one the most frowned upon feature of PHP and 
it 
is well overdue for a refactor. Old frameworks and application are a pain to 
convert, and it pretty pointless to do it for a cosmetic reason as rasmus 
pointed 
out, but I think the core devs are underestimating how much the community wants 
it done and how many people are willing to do their part.

Let’s face it:
 • htmlentities/html_entity_decode
 • str_replace/strtr
 • current/array_pop
 • array_push($array, $item)/array_search($item, $array)

I believe a very responsible roadmap would be to :

1. Create a PHP library that would essentially just wrap a function in another 
with consistent naming and arguments order.
2. Get some feedback of the community and work on the names. The guys at FIG 
would probably be a blessing on that.
3. Implement those using aliasing and a compiled extension.
4. Let it sit for a couple time while people get to know about it.
5. Merge extension into core. Real world application will begin to use it.
6. Drop the deprecated ones in a distant future.


Previous Comments:

[2013-01-23 17:06:11] lenton64 at gmail dot com

I feel that this is a big problem in PHP. It makes it super hard to remember 
function names (especially for newcomers) with these inconsistencies and gives 
PHP an ugly syntax reputation.

Please change all function names to:
words_separated_with_underscore()

and then alias the original functions to the new ones.

It may take a long time for everyone to change the functions in their 
applications but you can keep them aliased for however long everyone needs.

This naming convention needs to become a standard in PHP at some point, why not 
get the ball rolling now.


[2010-07-29 02:09:38] ras...@php.net

We don't mind change, but our users really really don't like it when we break 
their working applications for cosmetic reasons.


[2010-07-29 02:05:31] php-bugs at majkl578 dot cz

Yes and that is what I think should change, because current naming conventions 
are really horrible. For instance, look at differences between str_replace, 
strlen, parse_str, htmlspecialchars. All work with same type but their names 
are completely different.
So, string functions should go to String namespace (String\replace()), array 
functions to Array namespace (Array\search()) and so on.

But unfortunately this will not happen because PHP does not like changes... 
Think about it.


[2010-07-25 00:19:32] giorgio dot liscio at email dot it

php functions uses a lot of different syntax

isset
is_array
isPublic

but aliasing is evil and renaming is not appreciated by users... the best thing 
you can do is implement your renamed function in your namespace

bye


[2010-07-24 07:11:06] php-bugs at majkl578 dot cz

Description:

I suggest adding a function htmlentities_decode() as a replacement for 
html_entity_decode() and possibly deprecate that one.
It is really misleading and unintuitive because there are functions 
htmlspecialchars() and htmlspecialchars_decode() doing similar thing.







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

Bug #64057 [Opn-Fbk]: substr_replace failed charset utf-8

2013-01-23 Thread aharvey 
Edit report at https://bugs.php.net/bug.php?id=64057edit=1

 ID: 64057
 Updated by: ahar...@php.net
 Reported by:ltsujiguchi at gmail dot com
 Summary:substr_replace failed charset utf-8
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Strings related
 Operating System:   Ubuntu 12.10
 PHP Version:5.4.11
 Block user comment: N
 Private report: N

 New Comment:

Works fine for me too. Can you upload the entire file (preferably without 
copy/pasting), please?


Previous Comments:

[2013-01-23 21:46:03] mail+php at requinix dot net

Do you have one of those weird editors where shift+space produces something 
besides a regular space? It may sound stupid and probably won't change anything 
but try deleting the LIKE ? and typing it again carefully.

Also stupid and pointless, check that
  echo bin2hex($cond);
ends in ...4c494b45203f.


[2013-01-23 18:21:39] krak...@php.net

[joe@fiji php-5.4.6]$ nano 64057.php
[joe@fiji php-5.4.6]$ sapi/cli/php 64057.php
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE %é%

Anyone else ??


[2013-01-23 17:54:21] ltsujiguchi at gmail dot com

Description:

I had a problem when i used the substr_replace, using those changes os php.ini:

I couldn't find the exact version of my php on the drop, so i put the closest 
version, but my real version is the 5.4.6.

Result expected:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE %é%

Result returned:
noticia.noticia_titulo LIKE %é% OR noticia.noticia_conteudo LIKE%é%?

Test script:
---
$replacement = '%é%';
$cond = 'noticia.noticia_titulo LIKE ? OR noticia.noticia_conteudo LIKE ?';
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
$posItem = stripos($cond, '?');
$cond = substr_replace($cond, $replacement, $posItem, 1);
echo $cond;







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

Bug #52424 [Com]: Function naming inconsistency: htmlentities() x html_entity_decode()

2013-01-23 Thread nishant dot kanitkar at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=52424edit=1

 ID: 52424
 Comment by: nishant dot kanitkar at gmail dot com
 Reported by:php-bugs at majkl578 dot cz
 Summary:Function naming inconsistency: htmlentities() x
 html_entity_decode()
 Status: Wont fix
 Type:   Bug
 Package:Unknown/Other Function
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

I don't see why this can't be done. 

Alias the functions to a single standard and depreciate the old ones.
In the next version of PHP, add a configuration toggle ALLOW_LEGACY_FUNCTIONS 
set to default false.

If ALLOW_LEGACY_FUNCTIONS is true, all the depreciated functions work as 
expected.
If ALLOW_LEGACY_FUNCTIONS is false, all the depreciated functions throw errors.

Keep the toggle in all future versions of PHP. Eventually applications using 
the legacy function names 
will either run a search-and-replace or fall out of use. It wouldn't be too 
difficult to migrate if the 
only change is a name change.


Previous Comments:

[2013-01-24 02:46:34] php at lavoie dot sl

The core functions’ naming is one the most frowned upon feature of PHP and 
it 
is well overdue for a refactor. Old frameworks and application are a pain to 
convert, and it pretty pointless to do it for a cosmetic reason as rasmus 
pointed 
out, but I think the core devs are underestimating how much the community wants 
it done and how many people are willing to do their part.

Let’s face it:
 • htmlentities/html_entity_decode
 • str_replace/strtr
 • current/array_pop
 • array_push($array, $item)/array_search($item, $array)

I believe a very responsible roadmap would be to :

1. Create a PHP library that would essentially just wrap a function in another 
with consistent naming and arguments order.
2. Get some feedback of the community and work on the names. The guys at FIG 
would probably be a blessing on that.
3. Implement those using aliasing and a compiled extension.
4. Let it sit for a couple time while people get to know about it.
5. Merge extension into core. Real world application will begin to use it.
6. Drop the deprecated ones in a distant future.


[2013-01-23 17:06:11] lenton64 at gmail dot com

I feel that this is a big problem in PHP. It makes it super hard to remember 
function names (especially for newcomers) with these inconsistencies and gives 
PHP an ugly syntax reputation.

Please change all function names to:
words_separated_with_underscore()

and then alias the original functions to the new ones.

It may take a long time for everyone to change the functions in their 
applications but you can keep them aliased for however long everyone needs.

This naming convention needs to become a standard in PHP at some point, why not 
get the ball rolling now.


[2010-07-29 02:09:38] ras...@php.net

We don't mind change, but our users really really don't like it when we break 
their working applications for cosmetic reasons.


[2010-07-29 02:05:31] php-bugs at majkl578 dot cz

Yes and that is what I think should change, because current naming conventions 
are really horrible. For instance, look at differences between str_replace, 
strlen, parse_str, htmlspecialchars. All work with same type but their names 
are completely different.
So, string functions should go to String namespace (String\replace()), array 
functions to Array namespace (Array\search()) and so on.

But unfortunately this will not happen because PHP does not like changes... 
Think about it.


[2010-07-25 00:19:32] giorgio dot liscio at email dot it

php functions uses a lot of different syntax

isset
is_array
isPublic

but aliasing is evil and renaming is not appreciated by users... the best thing 
you can do is implement your renamed function in your namespace

bye




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

https://bugs.php.net/bug.php?id=52424


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

Bug #40597 [Com]: FILTER_VALIDATE_INT limited to system's signed integer size

2013-01-23 Thread spam at redfishbluefishdesign dot com 
Edit report at https://bugs.php.net/bug.php?id=40597edit=1

 ID: 40597
 Comment by: spam at redfishbluefishdesign dot com
 Reported by:mail957253 at lemurtastic dot com
 Summary:FILTER_VALIDATE_INT limited to system's signed
 integer size
 Status: Not a bug
 Type:   Bug
 Package:Filter related
 Operating System:   Windows XP SP2
 PHP Version:5.2.1
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

Ya, this is a bug.


Previous Comments:

[2012-03-15 02:33:25] php dot 20 dot rinogo at xoxy dot net

I'm with the OP.  I'm migrating an app from HostMonster shared hosting to a 
WiredTree VPS.

On HM, filter_var runs as expected (as stated above).  On WiredTree, it returns 
false.

So, at BEST, PHP's behavior is inconsistent.


[2007-02-22 22:48:08] paj...@php.net

It returns a PHP integer which is limited to 32bits.

If you like to get a string containing a big integer, you can use the sanitize 
rule.

Once PHP has 64bits integer support, it will be available in filter as well.

Not a bug  bogus.


[2007-02-22 22:36:02] mail957253 at lemurtastic dot com

Description:

FILTER_VALIDATE_INT should validate anything that normal people consider an 
integer as such, rather than being limited to what my computer can store in 32 
bits.

Reproduce code:
---
filter_var('2147483648', FILTER_VALIDATE_INT);

Expected result:

returns '2147483648'

Actual result:
--
returns FALSE






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

Bug #62199 [Com]: is_readable() does not seem to tolerate crossing partitions inside a sambashare

2013-01-23 Thread lukx at lukx dot de 
Edit report at https://bugs.php.net/bug.php?id=62199edit=1

 ID: 62199
 Comment by: lukx at lukx dot de
 Reported by:moodboom at gmail dot com
 Summary:is_readable() does not seem to tolerate crossing
 partitions inside a sambashare
 Status: Open
 Type:   Bug
 Package:Directory function related
 Operating System:   linux (gentoo)
 PHP Version:5.3.13
 Block user comment: N
 Private report: N

 New Comment:

Bug #49620 seems to be similar and offers some more test cases.


Previous Comments:

[2012-05-31 18:05:40] moodboom at gmail dot com

Note that the C function access() (which I believe is used by is_readable()) 
works as expected:

C code: 

cout  share:   access(/remote/samba_share, R_OK)  endl; 
cout  local:   access(/remote/samba_share/local_dir, R_OK)  endl; 
cout  second:   access(/remote/samba_share/second_drive, R_OK)  endl; 
cout  raid:   access(/remote/samba_share/ext_raid, R_OK)  endl;

result: 

share: 0
local: 0
second: 0
raid: 0


[2012-05-31 17:43:41] moodboom at gmail dot com

Description:

Calls to PHP's is_readable() function are returning false on a directory that 
is readable from the command prompt. I have changed permissions to 
most-permissible and still no luck.

Any directory under the samba share that is not on the physical primary 
partition seems to fail. 

Here are the permissions as provided in the shell:

ls -lad /remote/samba_share
drwxrwxr-x 13 me users 0 May 29 15:49 /remote/samba_share

ls -la /remote/samba_share
drwxr-xr-x  4 me users 0 May  8 14:19 /remote/samba_share/local_dir
drwxr-xr-x 16 me users 0 May 14 19:49 /remote/samba_share/second_drive
drwxrwxrwx 12 me users 0 May 30 09:42 /remote/samba_share/ext_raid

NOTE: I started this as a question on stackoverflow, because of the number of 
other possible causes, but led to this bug report.

http://stackoverflow.com/questions/10818770/php-is-readable-fails-on-readable-samba-directory



Test script:
---
if (is_readable('/remote/samba_share'  )){ echo share ok\n;  } 
else { echo share BAD\n;  }
if (is_readable('/remote/samba_share/local_dir')){ echo local ok\n;  } 
else { echo local BAD\n;  }
if (is_readable('/remote/samba_share/second_drive' )){ echo second ok\n; } 
else { echo second BAD\n; }
if (is_readable('/remote/samba_share/ext_raid' )){ echo raid ok\n;   } 
else { echo raid BAD\n;   }

Expected result:

share ok
local ok
second ok
raid ok

Actual result:
--
share ok
local ok
second BAD
raid BAD






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