#42506 [NEW]: php_pgsql_convert' timezone parse bug
From: nonunnet at gmail dot com
Operating system: ANY
PHP version: 5.2.4
PHP Bug Type: PostgreSQL related
Bug description: php_pgsql_convert' timezone parse bug
Description:
'2007-01-01 01:01:01 Asia/Seoul'
'2007-01-01 01:01 America/Los_angeles'
regex '[a-zA-Z]{1,5}' cannot parse above strings.
regex change to '[-a-zA-Z_/+]{1,30}'
line 5004 on ext/pgsql/pgsql.c
- if (php_pgsql_convert_match(Z_STRVAL_PP(val),
^([0-9]{4}[/-][0-9]{1,2}[/-][0-9]{1,2})([
\\t]+(([0-9]{1,2}:[0-9]{1,2}){1}(:[0-9]{1,2}){0,1}(\\.[0-9]+){0,1}([
\\t]*([+-][0-9]{1,2}(:[0-9]{1,2}){0,1}|[a-zA-Z]{1,5})){0,1})){0,1}$, 1
TSRMLS_CC) == FAILURE) {
+ if (php_pgsql_convert_match(Z_STRVAL_PP(val),
^([0-9]{4}[/-][0-9]{1,2}[/-][0-9]{1,2})([
\\t]+(([0-9]{1,2}:[0-9]{1,2}){1}(:[0-9]{1,2}){0,1}(\\.[0-9]+){0,1}([
\\t]*([+-][0-9]{1,2}(:[0-9]{1,2}){0,1}|[-a-zA-Z_/+]{1,30})){0,1})){0,1}$,
1 TSRMLS_CC) == FAILURE) {
--
Edit bug report at http://bugs.php.net/?id=42506edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42506r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42506r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42506r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42506r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42506r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42506r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42506r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42506r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42506r=support
Expected behavior:http://bugs.php.net/fix.php?id=42506r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42506r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42506r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42506r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42506r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42506r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42506r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42506r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42506r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42506r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42506r=mysqlcfg
#42509 [NEW]: GMP without gmp_init eats memory
From: thomas dot hebinck at digionline dot de
Operating system: Linux
PHP version: 5.2.4
PHP Bug Type: *Math Functions
Bug description: GMP without gmp_init eats memory
Description:
Various GMP Functions eat memory, when not called directly with integers
or strings instead of gmp resources.
Reproduce code:
---
$a='1234';
for($i=0;$i20;$i++) {
$c=gmp_add(gmp_init($a),gmp_init($a));
}
echo memory_get_usage() . ¶\n;
for($i=0;$i20;$i++) {
$c=gmp_add($a,$a);
}
echo memory_get_usage() . ¶\n;
Expected result:
Both memory_get_usage() should show nearly the same values.
Actual result:
--
1732656¶// ~ 2 MB
43809696¶ // ~ 43 MB
--
Edit bug report at http://bugs.php.net/?id=42509edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42509r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42509r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42509r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42509r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42509r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42509r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42509r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42509r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42509r=support
Expected behavior:http://bugs.php.net/fix.php?id=42509r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42509r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42509r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42509r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42509r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42509r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42509r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42509r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42509r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42509r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42509r=mysqlcfg
#42510 [NEW]: unpack('V') sign-extends result on x86-64
From: jr-php2 at quo dot to
Operating system: Linux x86-64
PHP version: 5.2.4
PHP Bug Type: Unknown/Other Function
Bug description: unpack('V') sign-extends result on x86-64
Description:
On x86-64, unpack('V') sign-extends from 32-bit to 64-bit. In other words,
it can return a negative number.
Since 'V' specifies an *unsigned* 32-bit value, this is incorrect; the
upper 32 bits of the 64-bit result should always be zero.
This behavior makes unpack() inconsistent with other functions like
ip2long() and crc32() which never return negative numbers on 64-bit PHP.
Reproduce code:
---
$u = unpack('Vresult', chr(200).chr(200).chr(200).chr(200));
echo unpack = , $u['result'], \n;
echo ip2long = , ip2long('200.200.200.200'), \n;
Expected result:
unpack = -926365496
ip2long = 3368601800
Actual result:
--
unpack = 3368601800
ip2long = 3368601800
--
Edit bug report at http://bugs.php.net/?id=42510edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42510r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42510r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42510r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42510r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42510r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42510r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42510r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42510r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42510r=support
Expected behavior:http://bugs.php.net/fix.php?id=42510r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42510r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42510r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42510r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42510r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42510r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42510r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42510r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42510r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42510r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42510r=mysqlcfg
#42510 [Opn]: unpack('V') sign-extends result on x86-64
ID: 42510
User updated by: jr-php2 at quo dot to
Reported By: jr-php2 at quo dot to
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux x86-64
PHP Version: 5.2.4
New Comment:
Sorry, I mixed up the expected and actual results.
It should say:
Expected result:
unpack = 3368601800
ip2long = 3368601800
Actual result:
--
unpack = -926365496
ip2long = 3368601800
Previous Comments:
[2007-09-01 17:22:10] jr-php2 at quo dot to
Description:
On x86-64, unpack('V') sign-extends from 32-bit to 64-bit. In other
words, it can return a negative number.
Since 'V' specifies an *unsigned* 32-bit value, this is incorrect; the
upper 32 bits of the 64-bit result should always be zero.
This behavior makes unpack() inconsistent with other functions like
ip2long() and crc32() which never return negative numbers on 64-bit PHP.
Reproduce code:
---
$u = unpack('Vresult', chr(200).chr(200).chr(200).chr(200));
echo unpack = , $u['result'], \n;
echo ip2long = , ip2long('200.200.200.200'), \n;
Expected result:
unpack = -926365496
ip2long = 3368601800
Actual result:
--
unpack = 3368601800
ip2long = 3368601800
--
Edit this bug report at http://bugs.php.net/?id=42510edit=1
#42298 [Asn-Csd]: preg_match with /u gives different results for \S\S and \S{2}
ID: 42298
Updated by: [EMAIL PROTECTED]
Reported By: matthew-php at dracos dot co dot uk
-Status: Assigned
+Status: Closed
Bug Type: PCRE related
Operating System: Windows XP
PHP Version: 5CVS-2007-08-14 (snap)
Assigned To: nlopess
New Comment:
bug fixed in PCRE 7.3.
I've upgraded the bundled PCRE package in php 5.2 and 6 branches.
Previous Comments:
[2007-08-15 09:02:22] [EMAIL PROTECTED]
submited upstream: http://bugs.exim.org/580
I will provide more feedback when I end my vacations.
[2007-08-15 08:43:03] [EMAIL PROTECTED]
Assigned to PCRE maintainer.
[2007-08-14 16:46:48] matthew-php at dracos dot co dot uk
Description:
When using the /u modifier, preg_match, preg_match_all, and
preg_replace all give incorrect results using /\S{2}/u but work fine
with /\S\S/u which should be equivalent.
Reproduce code:
---
$s = A\xc2\xa3BC;
preg_match_all('/\S\S/u', $s, $m);
print_r($m[0]);
preg_match_all('/\S{2}/u', $s, $m);
print_r($m[0]);
Expected result:
Array
(
[0] = A£
[1] = BC
)
Array
(
[0] = A£
[1] = BC
)
Actual result:
--
Array
(
[0] = A£
[1] = BC
)
Array
(
[0] = A
[1] =
)
--
Edit this bug report at http://bugs.php.net/?id=42298edit=1
#42511 [NEW]: When using the CGI SAPI, Zend Extensions fail to load
From: schneecrash+php at gmail dot com Operating system: OSX, FreeBSD, Linux PHP version: 5CVS-2007-09-01 (CVS) PHP Bug Type: CGI related Bug description: When using the CGI SAPI, Zend Extensions fail to load Description: When using the CGI SAPI, Zend Extensions fail to load (and/or?) report as loaded. This issue was originally reported as a continuing comment to CGI SAPI does not shut down cleanly with -i/-m/-v cmdline options http://bugs.php.net/bug.php?id=42453 but that bug was closed nonetheless. Reproduce code: --- With CLI SAPI: # php -v PHP 5.2.5-dev (cli) (built: Aug 31 2007 08:33:23) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.6-dev, Copyright (c) 2004-2007 eAccelerator, by eAccelerator with Xdebug v2.1.0-dev, Copyright (c) 2002, 2003, 2004, 2005, 2006, 2007, by Derick Rethans With CGI SAPI: # php-cgi -v PHP 5.2.5-dev (cgi-fcgi) (built: Aug 31 2007 08:34:02) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies Expected result: same loading and report of loaded extensions in case of *both* php php-cgi Actual result: -- CLI SAPI loads reports extensions, CLI SAPI does not -- Edit bug report at http://bugs.php.net/?id=42511edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42511r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42511r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42511r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42511r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42511r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42511r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42511r=needscript Try newer version:http://bugs.php.net/fix.php?id=42511r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42511r=support Expected behavior:http://bugs.php.net/fix.php?id=42511r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42511r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42511r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42511r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42511r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42511r=dst IIS Stability:http://bugs.php.net/fix.php?id=42511r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42511r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42511r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42511r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42511r=mysqlcfg
#42512 [NEW]: ip2long('255.255.255.255') should return 4294967295 on 64-bit PHP
From: jr-php2 at quo dot to
Operating system: Linux x86-64
PHP version: 5.2.4
PHP Bug Type: Network related
Bug description: ip2long('255.255.255.255') should return 4294967295 on 64-bit
PHP
Description:
On 64-bit platforms, ip2long() returns a positive result for IP addresses
= 128.0.0.0. This is expected.
However, there is *one* case in which it will return a negative result:
when the specified address is 255.255.255.255.
This inconsistency doesn't make sense. Yes, the documentation does say
that ip2long() returns -1 for 255.255.255.255, but that should only be the
case on 32-bit platforms, where all addresses = 128.0.0.0 return a
negative result.
Reproduce code:
---
echo ip2long('255.255.255.254') = , ip2long('255.255.255.254'), \n;
echo ip2long('255.255.255.255') = , ip2long('255.255.255.255'), \n;
Expected result:
ip2long('255.255.255.254') = 4294967294
ip2long('255.255.255.255') = 4294967295
Actual result:
--
ip2long('255.255.255.254') = 4294967294
ip2long('255.255.255.255') = -1
--
Edit bug report at http://bugs.php.net/?id=42512edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42512r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42512r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42512r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42512r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42512r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42512r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42512r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42512r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42512r=support
Expected behavior:http://bugs.php.net/fix.php?id=42512r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42512r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42512r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42512r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42512r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42512r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42512r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42512r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42512r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42512r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42512r=mysqlcfg
#42513 [NEW]: extensions_dir syntax bug
From: mshockle at gmail dot com Operating system: windows xp PHP version: 5.2.4 PHP Bug Type: *General Issues Bug description: extensions_dir syntax bug Description: on windows xp running apache 2.2.4, with php 5.2.4.4 (and earlier versions IIRC) if extension_dir is extension_dir = E:\php\ext it cannot load any modules located therein, this is also true for ./ and other relative paths. However extension_dir = E:\php\ext works fine, and similarly with all other circumstances. this occurred with php_mysql, php_mysqli, php_mbstring, and any other module I installed. -- Edit bug report at http://bugs.php.net/?id=42513edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42513r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42513r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42513r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42513r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42513r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42513r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42513r=needscript Try newer version:http://bugs.php.net/fix.php?id=42513r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42513r=support Expected behavior:http://bugs.php.net/fix.php?id=42513r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42513r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42513r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42513r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42513r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42513r=dst IIS Stability:http://bugs.php.net/fix.php?id=42513r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42513r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42513r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42513r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42513r=mysqlcfg
#42512 [Opn-Asn]: ip2long('255.255.255.255') should return 4294967295 on 64-bit PHP
ID: 42512
Updated by: [EMAIL PROTECTED]
Reported By: jr-php2 at quo dot to
-Status: Open
+Status: Assigned
Bug Type: Network related
Operating System: Linux x86-64
PHP Version: 5.2.4
-Assigned To:
+Assigned To: derick
New Comment:
Confirmed, and testing a patch.
Previous Comments:
[2007-09-01 18:10:25] jr-php2 at quo dot to
Description:
On 64-bit platforms, ip2long() returns a positive result for IP
addresses = 128.0.0.0. This is expected.
However, there is *one* case in which it will return a negative result:
when the specified address is 255.255.255.255.
This inconsistency doesn't make sense. Yes, the documentation does say
that ip2long() returns -1 for 255.255.255.255, but that should only be
the case on 32-bit platforms, where all addresses = 128.0.0.0 return a
negative result.
Reproduce code:
---
echo ip2long('255.255.255.254') = , ip2long('255.255.255.254'),
\n;
echo ip2long('255.255.255.255') = , ip2long('255.255.255.255'), \n;
Expected result:
ip2long('255.255.255.254') = 4294967294
ip2long('255.255.255.255') = 4294967295
Actual result:
--
ip2long('255.255.255.254') = 4294967294
ip2long('255.255.255.255') = -1
--
Edit this bug report at http://bugs.php.net/?id=42512edit=1
#42512 [Asn-Csd]: ip2long('255.255.255.255') should return 4294967295 on 64-bit PHP
ID: 42512
Updated by: [EMAIL PROTECTED]
Reported By: jr-php2 at quo dot to
-Status: Assigned
+Status: Closed
Bug Type: Network related
Operating System: Linux x86-64
PHP Version: 5.2.4
Assigned To: derick
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-09-01 18:29:38] [EMAIL PROTECTED]
Confirmed, and testing a patch.
[2007-09-01 18:10:25] jr-php2 at quo dot to
Description:
On 64-bit platforms, ip2long() returns a positive result for IP
addresses = 128.0.0.0. This is expected.
However, there is *one* case in which it will return a negative result:
when the specified address is 255.255.255.255.
This inconsistency doesn't make sense. Yes, the documentation does say
that ip2long() returns -1 for 255.255.255.255, but that should only be
the case on 32-bit platforms, where all addresses = 128.0.0.0 return a
negative result.
Reproduce code:
---
echo ip2long('255.255.255.254') = , ip2long('255.255.255.254'),
\n;
echo ip2long('255.255.255.255') = , ip2long('255.255.255.255'), \n;
Expected result:
ip2long('255.255.255.254') = 4294967294
ip2long('255.255.255.255') = 4294967295
Actual result:
--
ip2long('255.255.255.254') = 4294967294
ip2long('255.255.255.255') = -1
--
Edit this bug report at http://bugs.php.net/?id=42512edit=1
#42510 [Opn]: unpack('V') sign-extends result on x86-64
ID: 42510
User updated by: jr-php2 at quo dot to
Reported By: jr-php2 at quo dot to
Status: Open
Bug Type: Unknown/Other Function
Operating System: Linux x86-64
PHP Version: 5.2.4
New Comment:
Okay, looking at the unpack() code, it appears that:
- 'l' and 'L' are both treated as signed, even though 'l' is documented
as signed and 'L' is documented as unsigned.
- 'N' and 'V' are treated as signed, even though both are documented as
unsigned.
So who's right here, the code or the documentation?
Previous Comments:
[2007-09-01 17:26:12] jr-php2 at quo dot to
Sorry, I mixed up the expected and actual results.
It should say:
Expected result:
unpack = 3368601800
ip2long = 3368601800
Actual result:
--
unpack = -926365496
ip2long = 3368601800
[2007-09-01 17:22:10] jr-php2 at quo dot to
Description:
On x86-64, unpack('V') sign-extends from 32-bit to 64-bit. In other
words, it can return a negative number.
Since 'V' specifies an *unsigned* 32-bit value, this is incorrect; the
upper 32 bits of the 64-bit result should always be zero.
This behavior makes unpack() inconsistent with other functions like
ip2long() and crc32() which never return negative numbers on 64-bit PHP.
Reproduce code:
---
$u = unpack('Vresult', chr(200).chr(200).chr(200).chr(200));
echo unpack = , $u['result'], \n;
echo ip2long = , ip2long('200.200.200.200'), \n;
Expected result:
unpack = -926365496
ip2long = 3368601800
Actual result:
--
unpack = 3368601800
ip2long = 3368601800
--
Edit this bug report at http://bugs.php.net/?id=42510edit=1
#42516 [NEW]: __FILE__ resolves symlinks - not mentioned in manual
From: michael at zedeler dot dk Operating system: Linux PHP version: 4.4.7 PHP Bug Type: Filesystem function related Bug description: __FILE__ resolves symlinks - not mentioned in manual Description: __FILE__ does not return the path used to invoke the current file, but resolves symlinks. This behaviour is extremely problematics, since important information is thrown away. The web is teeming with postings from people that are experiencing problems because of this. In http://bugs.php.net/bug.php?id=37603 this bug was mentioned and the response was that it is intended behavior with a reference to the manual. The page http://es.php.net/manual/en/language.constants.predefined.php is the primary source of information for __FILE__, and it does not mention resolving symlinks at all. I'd like if we could have som kind of dialogue about how to solve the problem, in stead of just having this bug being closed with a Bogus status. My suggestions are: 1) introduce a new magical constant that behaves as it should. 2) put a parameter in php.ini that changes how __FILE__ behaves. Reproduce code: --- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Expected result: This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Actual result: -- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 -- Edit bug report at http://bugs.php.net/?id=42516edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42516r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42516r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42516r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42516r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42516r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42516r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42516r=needscript Try newer version:http://bugs.php.net/fix.php?id=42516r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42516r=support Expected behavior:http://bugs.php.net/fix.php?id=42516r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42516r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42516r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42516r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42516r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42516r=dst IIS Stability:http://bugs.php.net/fix.php?id=42516r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42516r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42516r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42516r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42516r=mysqlcfg
#42438 [Fbk-Opn]: require require_once include include_once
ID: 42438 User updated by: perching_eagle at yahoo dot com Reported By: perching_eagle at yahoo dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: windows xp PHP Version: 5.2.3 New Comment: i guess i have to give up, if it works on linux then i will eventually have to make the transition to linux. i did try your last suggestion and it didn't work, but i will try it a few more times and then if my problem remains unsolved, i will switch to linux earlier than i had planned. and you may close this thread. thanks for your help. Previous Comments: [2007-08-30 09:46:17] [EMAIL PROTECTED] When you installed the snapshot, did you first shutdown whatever webserver you use and delete (!!) all old installed PHP related dlls/executables BEFORE you installed the snapshot version?? I can't reproduce this on Windows XP (yes, I have that..) nor on Linux (preferred OS). I suspect it's simply bad installation. [2007-08-30 06:01:25] perching_eagle at yahoo dot com one more thing i went to google translate to check what language was being dumped on my screen, and it was only the chinese to english translator that was able to decipher it, the words were meaningless but i wonder why. i hope someone can get to the bottom of this, the only solution i have right now is to manually copy all the files i would have included with the include or require directives, into one file for each class definition. the include,require,require_once,include_once all worked for non-object oriented programs. whenever it encountered the $this- operator in my code, especially in the constructor (just like the code in my first post), it dumps everything else after the $this- operator on my screen. [2007-08-30 02:17:15] perching_eagle at yahoo dot com not loading mbstrings didn't change anything, versions prior to 5.2.3 work well with no problem at all. i guess anyone that still uses a microsoft os like xp, can comfirm my complaint. well thanks jani for your help. if you have access to windows xp with php 5.2.3 installed on it, you may be able to figure out what the problem is. till then bye.. [2007-08-28 21:42:01] [EMAIL PROTECTED] Well, do you get readable error messages when you don't load mbstring? (this is getting quite boring..) [2007-08-28 18:57:35] perching_eagle at yahoo dot com i followed your advice, set display_errors to On and error_reporting to E_ALL, it didn't do much help but when i set the error_reporting to E_ALL E_STRICT the japanese characters disappeared from the output of my code when using a php editor (i use php designer), however nothing changed when i tried display my output on a browser window using apache httpd. i also noticed some comments or non-directives in the php ini file, that were not properly commented with ; and correcting them still didn't help. i also think that in the window edition of php 5.2.3 download, mb_string language was set to japanese by default, even for english language speakers, and those japanese characters dumped on the output screen from my code, could be error messages automatically translated into japanese. 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/42438 -- Edit this bug report at http://bugs.php.net/?id=42438edit=1
#42517 [NEW]: set_include_path('') doesn't work as expected
From: php at ideacode dot com
Operating system: Linux
PHP version: 5.2.4
PHP Bug Type: Feature/Change Request
Bug description: set_include_path('') doesn't work as expected
Description:
There are legitimate secure-operation situations when you want the
include path wiped out, so that all included files must be explicitly
stated.
The obvious way to set this is with either:
set_include_path(''); // or
ini_set('include_path', '');
However, neither one of these sets the include path to '' on the latest
version of PHP 4 or PHP 5 in Linux.
A non-obvious workaround is to use a whitespace string:
set_include_path(' '); // or
ini_set('include_path', ' ');
which does set the path to ' ' (which hopefully isn't a valid
directory!).
I believe passing a lambda string to either set_include_path or
ini_set('include_path') should set the path to the lambda string.
http://bytejar.com/ - Software Lessons Learned the Hard Way
Reproduce code:
---
$original_path = set_include_path('');
Expected result:
'' === get_include_path();
Actual result:
--
$original_path === get_include_path();
--
Edit bug report at http://bugs.php.net/?id=42517edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42517r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42517r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42517r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42517r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42517r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42517r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42517r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42517r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42517r=support
Expected behavior:http://bugs.php.net/fix.php?id=42517r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42517r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42517r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42517r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42517r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42517r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42517r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42517r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42517r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42517r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42517r=mysqlcfg
