Req #3799 [Com]: default_charset brings small incompatibility
Edit report at https://bugs.php.net/bug.php?id=3799&edit=1 ID: 3799 Comment by: cmbecker69 at gmx dot de Reported by:k at les dot cz Summary:default_charset brings small incompatibility Status: Suspended Type: Feature/Change Request Package:Feature/Change Request PHP Version:4.0 Latest CVS (10/03/2000) Block user comment: N Private report: N New Comment: According to the manual[1] default_charset already defaults to '', what has the desired effect. A test conformed that even for the windows binary of PHP-4.3.11. It seems to me, the request should be finally closed. [1] <http://www.php.net/manual/en/ini.core.php#ini.default-charset> Previous Comments: [2000-08-02 12:15:29] j...@php.net I can almost promise this is never going to happen. The default_charset was created to make the "default install" of php [more] secure against the "cross site scripting" bug. For more info, please see the CERT Advisory: http://www.cert.org/advisories/CA-2000-02.html [2000-08-01 17:34:11] waldschr...@php.net If that´s true, it´ll really make sense [2000-08-01 17:28:12] k at les dot cz the problem is that if you're installing a new software you don't suppose it's preconfigured for a special charset. of course, even if you're a newbie, you'll get it after some investigation :) the point of this request is - if default_charset were set to "none" by default, if would work for everyone by default. if it's set to anything else, it works "only" for iso-latin1 users. [2000-08-01 14:06:09] waldschr...@php.net Where is the problem for a newbie to have a look on the php.ini file, or am I missing sth? [2000-08-01 13:45:31] k at les dot cz oops.. i was talking about NEW php users of course... the problem is in modules for charset conversion, they are getting confused by iso-latin1 header, and it's hard for newbies to solve it... at least it was hard for experienced users when this new feature appeared :) 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=3799 -- Edit this bug report at https://bugs.php.net/bug.php?id=3799&edit=1
Bug #64332 [Com]: Problems with BR Save time (BRST)
Edit report at https://bugs.php.net/bug.php?id=64332&edit=1
ID: 64332
Comment by: cmbecker69 at gmx dot de
Reported by:bernardo at datamex dot com dot br
Summary:Problems with BR Save time (BRST)
Status: Open
Type: Bug
Package:Date/time related
Operating System: Window,Linux,FreeBSD
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
If I'm not mistaken the "actual results" are correct, and the
"expected results" are wrong. At least according to Wikipedia[1]
America/Sao_Paulo and America/Bahia have the same offset to UTC
and identical DST offset.
If so, this is not a bug (but rather an older bug was fixed).
[1] <http://en.wikipedia.org/wiki/Bras%C3%ADlia_Summer_Time>
Previous Comments:
[2013-03-01 17:59:17] bernardo at datamex dot com dot br
Description:
I changed my server application before Freebsd with php 5.3.3 now Ubuntu with
php
5.3.10.
I noticed that there are differences between treatment dates in different
timezones.
Note that when BRST "America/Sao_Paulo" advances one hour.
Test script:
---
NOWIn BRST ({$time})
{$timezone}{$agoraAqui}{$antesAqui}
America/Bahia{$agoraLa}{$antesLa}
time-brazil
";
?>
Expected result:
NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00
Actual result:
--
Correct in:
- freebsd + php 5.3.3
- freebsd + php 5.3.6
- windows + php 5.3.8
NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 11:00:00
Error in:
- freebsd + php 5.3.10
- ubuntu + php 5.3.10
- windows + php 5.4.3
NOW | In BRST (1358258400)
America/Sao_Paulo | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
America/Bahia | 01/03/2013 14:46:27 | 15/01/2013 12:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=64332&edit=1
Bug #53397 [Com]: Modulo is not accurate with double
Edit report at https://bugs.php.net/bug.php?id=53397&edit=1 ID: 53397 Comment by: cmbecker69 at gmx dot de Reported by:mryaggi at hotmail dot com Summary:Modulo is not accurate with double Status: Verified Type: Bug Package:Scripting Engine problem Operating System: All PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The operation a - (floor(a/b)*b) gives not the modulo, but the remainder. Furthermore it seems the suggested patch does neither cater for large divisors nor large results. It *might* be reasonable to stick with the current implementation, and to state clearly in the documentation[1] that the modulus operator gives correct results only for integers in the range [-PHP_INT_MAX - 1, PHP_INT_MAX]. The current wording is somewhat misleading, IMHO. [1] <http://www.php.net/manual/en/language.operators.arithmetic.php> Previous Comments: [2013-08-06 08:28:02] yohg...@php.net Test with 5.5.1 32bit. This issue exists still. [2010-11-24 15:12:40] mryaggi at hotmail dot com Description: In C++ : 129059460 % 8640 = 3780 //correct But In PHP : 129059460 % 8640 = 30811200 //wrong However, in PHP : 129059460 - (floor(129059460/8640)*8640) = 3780 //correct! Can modulo opertor be implemented this way when left value > PHP_INT_MAX ? See Patch in attachement Test script: --- echo 129059460 % 8640; echo "\n"; echo 129059460 - (floor(129059460/8640)*8640); Expected result: 3780 3780 Actual result: -- 30811200 3780 -- Edit this bug report at https://bugs.php.net/bug.php?id=53397&edit=1
Bug #52261 [Com]: strtotime() worng result when timezome only.
Edit report at https://bugs.php.net/bug.php?id=52261&edit=1
ID: 52261
Comment by: cmbecker69 at gmx dot de
Reported by:n-ishii at chiether dot net
Summary:strtotime() worng result when timezome only.
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.2
Block user comment: N
Private report: N
New Comment:
The actual results are absolutely fine, e.g.
> UTC: 2010-07-06 02:58:03
> JST: 2010-07-06 11:58:03 (UTC +9)
UTC+9 means, add 9 hours to the time expressed as UTC and you
get the local time (JST).
IMHO this is not a bug.
Previous Comments:
[2010-07-06 07:29:54] n-ishii at chiether dot net
sorry mistake posted.
-> (timezone:JST) time-value on "2010-07-07 01:58:03 JST"
[2010-07-06 07:24:13] n-ishii at chiether dot net
or is it design?
so example...,
EST: 2010-07-05 21:58:03 (-5h)
UTC: 2010-07-06 02:58:03 ( 0h)
JST: 2010-07-06 11:58:03 (+9h) * local timezone.
strtotime("EST");
-> (localdate+EST) "2010-07-06 11:58:03 EST"
-> (convert UTC) "2010-07-06 16:58:03 UTC"
-> (timezone:JST) time-value on "2010-07-06 01:58:03 JST"
[2010-07-06 05:11:40] n-ishii at chiether dot net
Description:
Time Formats: tz format (JST, UTC, GMT, EST...) has problem. maybe wrong (+/-)
Test script:
---
[Date]
; Defines the default timezone used by the date functions
date.timezone = "Asia/Tokyo"
https://bugs.php.net/bug.php?id=52261&edit=1
Bug #45712 [Com]: $something == NaN returns true with 5.3, false with 5.2.*
Edit report at https://bugs.php.net/bug.php?id=45712&edit=1
ID: 45712
Comment by: cmbecker69 at gmx dot de
Reported by:for-bugs at hnw dot jp
Summary:$something == NaN returns true with 5.3, false with
5.2.*
Status: Re-Opened
Type: Bug
Package:Variables related
Operating System: *
PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-05)
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
> Please explain.
It seems there was a bug *before* PHP 5.4, because if $a === $b,
then $a == $b by definition.
Previous Comments:
[2011-05-26 07:59:24] phi...@php.net
Reopening because the associated test tests INF as well. However, this is about
INF:
// 5.3.7-dev (and all past PHP versions, afaict)
$inf = pow(0,-2); var_dump($inf==$inf); var_dump($inf===$inf); // false true
// 5.4.0-dev
$inf = pow(0,-2); var_dump($inf==$inf); var_dump($inf===$inf); // true true
Please explain.
And @jwvdveer, it was indeed fixed (in 5.3) and made to return false.
[2010-07-28 01:28:53] jwvdveer at gmail dot com
Please, reopen this bug. It's not working in PHP 5.3.3 on Windows platform
(released at 2010-07-21).
The behaviour of a comparison to NAN is the same as noted here.
It's not just a `me too`, but this thread shouln't have been closed.
[2008-08-07 08:36:33] tony2...@php.net
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.
[2008-08-07 07:37:04] tony2...@php.net
I'm testing a patch for it.
[2008-08-05 12:52:06] for-bugs at hnw dot jp
NaN is not exact number. So, NaN should not equals itself. Additionaly, NaN ==
NaN is false in C. You can see behavior of C as follows.
$ cat nan.c
int main() {double d;d=(-1e300*1e300)/(1e300*1e300);if (d==d) return 1; else
return 2;}
$ gcc nan.c; ./a.out; echo $?
2
$
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=45712
--
Edit this bug report at https://bugs.php.net/bug.php?id=45712&edit=1
Bug #48858 [Com]: array item definition problem (regression!)
Edit report at https://bugs.php.net/bug.php?id=48858&edit=1
ID: 48858
Comment by: cmbecker69 at gmx dot de
Reported by:justin dot carlson at gmail dot com
Summary:array item definition problem (regression!)
Status: Verified
Type: Bug
Package:Scripting Engine problem
Operating System: *
PHP Version:5.3.0
Block user comment: N
Private report: N
New Comment:
According to <http://3v4l.org/ahcBe> this behavior has already
been fixed with PHP 5.3.7.
Previous Comments:
[2009-12-08 08:36:54] mp at webfactory dot de
The problem only occurs when the array is initialized in the variable
declaration statement in the class AND class constants (with identical values)
are used as keys.
[2009-07-09 14:37:30] justin dot carlson at gmail dot com
I've confirmed this in Linux as well.
The following works fine:
'foo', b => 'bar');
print_R($test);
?>
So, it may be related to class constants?
[2009-07-09 07:25:39] sjoerd-php at linuxonly dot nl
Thank you for your bug report.
I was able to reproduce the problem and make the testcase somewhat simpler:
'First',
self::D => 'Last'
);
}
print_r(Foo::$sample);
?>
[2009-07-08 22:15:10] justin dot carlson at gmail dot com
Description:
Array items are not as defined when using the same key twice.
I have not yet tested this outside of a class.
Reproduce code:
---
'Apple',
self::B => 'Boy',
self::C => 'Cat',
self::D => 'Dog'
);
public static function Bar() {
print_R( self::$sample );
}
}
?>
Expected result:
In PHP 5.2.x:
Array
(
[2] => Boy
[3] => Cat
[1] => Dog
)
This is what I would expect to be valid, as the 2nd entry would override the
first, making "Dog" the correct value for index 1.
Actual result:
--
In PHP 5.3.x:
Array
(
[1] => Apple
[2] => Boy
[3] => Cat
)
This was not expected, as the 1st entry maintained it's value.
--
Edit this bug report at https://bugs.php.net/bug.php?id=48858&edit=1
Bug #64874 [Com]: json_decode handles whitespace and case-sensitivity incorrectly
Edit report at https://bugs.php.net/bug.php?id=64874&edit=1
ID: 64874
Comment by: cmbecker69 at gmx dot de
Reported by:chrivers at iversen-net dot dk
Summary:json_decode handles whitespace and case-sensitivity
incorrectly
Status: Open
Type: Bug
Package:JSON related
Operating System: All
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
There is a RFC[1] to replace the current JSON implementation with
the jsonc PECL extension, so "fixing" that implementation may not
be reasonable anyway.
[1] <https://wiki.php.net/rfc/free-json-parser>
Previous Comments:
[2013-09-09 16:24:12] ajf at ajf dot me
D:\Projects>php -r "var_dump(json_decode('tRUe'));"
bool(true)
Seems to still be broken, I'll try to fix it.
[2013-05-19 20:04:53] chrivers at iversen-net dot dk
Well, the part of the RFC that you're quoting describes the "JSON-text" type,
which indeed must be non-
primitive.
However, the json_decode() function is documented as taking a "json value",
which according to the spec
is
"""
A JSON value MUST be an object, array, number, or string, or one of
the following three literal names:
false null true
"""
So that's perfectly fine, really.
There are other errors, too. For example, " true" WORKS while "true " fails,
which makes no sense at
all. I've created an updated test case:
0],
$error[json_decode($x) !== $y]
);
}
printf($fmt, "JSON", "Expected", "Actual", "JSON_ERROR", "PASS");
printf("--
\n");
// works
json_cmp("true", true);
// fails - is actually true
json_cmp("tRue", NULL);
// fails - is actually NULL
json_cmp("true ", true);
// works
json_cmp("[true ] ", array(true));
json_cmp("[ true ] ", array(true));
json_cmp("[true] ", array(true));
// works, even though the non-array version fails
json_cmp("[tRue]", NULL);
json_cmp("0", 0);
json_cmp("1", 1);
json_cmp("false", false);
json_cmp("'foo'", NULL);
json_cmp('"foo"', "foo");
json_cmp('1.123', 1.123);
json_cmp('1.123 ', 1.123);
json_cmp(' 1.123', 1.123);
json_cmp('42', 42);
json_cmp('42 ', 42);
json_cmp(' 42', 42);
json_cmp(".123", 0.123);
?>
Which gives the following results:
JSON Expected Actual JSON_ERROR PASS
--
'true' true true - -
'tRue' NULL true - FAIL
'true ' true NULL FAIL FAIL
'[true ] ' array ( 0 => true,) array ( 0 => true,) - -
'[ true ] ' array ( 0 => true,) array ( 0 => true,) - -
'[true] 'array ( 0 => true,) array ( 0 => true,) - -
'[tRue]' NULL NULL FAIL -
'0' 00- -
'1' 11- -
'false' falsefalse- -
'\'foo\''NULL NULL FAIL -
'"foo"' 'foo''foo'- -
'1.123' 1.1231.123 - -
'1.123 ' 1.123NULL FAIL FAIL
' 1.123' 1.1231.123- -
'42' 42 42 - -
'42 '42 NULL FAIL FAIL
' 42'42 42 - -
'.123' 0.1230.123- -
I see "FAIL" 4 times, so that seems like 4 bugs to me.
[2013-05-18 15:00:32] cmbecker69 at gmx dot de
RFC 4627[1] also states in section 2:
| A JSON text is a serialized object or array.
|
|JSON-text = object / array
According to that definition the $json
Bug #65630 [Com]: filter_var() return false with german umlauts
Edit report at https://bugs.php.net/bug.php?id=65630&edit=1 ID: 65630 Comment by: cmbecker69 at gmx dot de Reported by:marvin-wegener at outlook dot com Summary:filter_var() return false with german umlauts Status: Open Type: Bug Package:Filter related Operating System: Windows/Linux PHP Version:5.5.3 Block user comment: N Private report: N New Comment: Unfortunately, the manual[1] is not explicit about that issue, but I assume that FILTER_VALIDATE_EMAIL validates according to RFC 5322, which does not cater for IDNs. If so, this might be regarded as "documentation problem". This bug report is related to request #65385[2]. [1] <http://www.php.net/manual/en/filter.filters.validate.php> [2] <https://bugs.php.net/bug.php?id=65385> Previous Comments: [2013-09-07 16:16:08] marvin-wegener at outlook dot com Description: Hello, If I use the following script, the filter_var return always false, but the Domain is possible. It is possible to fix it, that Domains with ÃÃÃ are exepted? Thanks you in advance! Test script: --- -- Edit this bug report at https://bugs.php.net/bug.php?id=65630&edit=1
Bug #65635 [Com]: cannot dereference array
Edit report at https://bugs.php.net/bug.php?id=65635&edit=1
ID: 65635
Comment by: cmbecker69 at gmx dot de
Reported by:TorrAB at Yahoo dot com
Summary:cannot dereference array
Status: Open
Type: Bug
Package:Compile Failure
Operating System: Windows XP
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
> Apparently, the parser cannot dereference $Apt['Color'].
No. The parser won't just accept this syntax. See the manual[1]
on how to use array indexes in strings.
IMHO, this is not a bug.
[1]
<http://www.php.net/manual/en/language.types.string.php#language.types.string.pars
ing.simple>
Previous Comments:
[2013-09-08 18:57:46] TorrAB at Yahoo dot com
Description:
Parse error: syntax error, unexpected "(T_ENCAPSED_AND_WHITESPACE), expecting
identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING).
Apparently, the parser cannot dereference $Apt['Color']. May be linked to bug
23022. But why the ?
Test script:
---
$Apt){
$Colo=$Apt['Color'];
echo "";
echo '';}
#Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE),
expecting identifier (T_STRING) or variable (T_VARIABLE) or number
(T_NUM_STRING) in C:\Apache24\htdocs\GoodBadB.php on line 10:
forEach ($GLOBALS['Aps'] as $GLOBALS['X'] => $Apt){
echo "";
#Apparently, the parser cannot dereference $Apt['Color']. May be linked to bug
23022. But why the ?
echo '';}
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=65635&edit=1
[PHP-BUG] Req #65626 [NEW]: uniqid(null, false) should guarantee unique identifier
From: cmbecker69 at gmx dot de Operating system: WIN32 PHP version: 5.4.19 Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:uniqid(null, false) should guarantee unique identifier Description: >From looking at the sources[1], it occurs to me that uniqid(null, false) doesn't *guarantee* to return a unique identifier on WIN32, because usleep(3) is skipped. As usleep() is implemented as PHP userland function since PHP 5.0.0[2], it seems to be reasonable and possible to add the equivalent to usleep(3) there. As far as I can tell, this won't introduce any BC issues, so the change might be done for PHP 5.4.x. Please note that this is related to #37106[3], but helly's comment doesn't seem to fit to the current sources. [1] <http://lxr.php.net/xref/PHP_5_4/ext/standard/uniqid.c#61> [2] <http://lxr.php.net/xref/PHP_5_4/win32/time.c#96> [3] <https://bugs.php.net/bug.php?id=37106> Test script: --- var_dump(uniqid(null, false) != uniqid(null, false)); Expected result: bool(true) Actual result: -- bool(false) // at least sometimes on a fast machine ;) -- Edit bug report at https://bugs.php.net/bug.php?id=65626&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65626&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65626&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65626&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65626&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65626&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65626&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65626&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65626&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65626&r=support Expected behavior: https://bugs.php.net/fix.php?id=65626&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65626&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65626&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65626&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65626&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65626&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65626&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65626&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65626&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65626&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65626&r=mysqlcfg
Req #27182 [Com]: [Patch] uniqid("prefix", 0) now works under recent cygwin
Edit report at https://bugs.php.net/bug.php?id=27182&edit=1
ID: 27182
Comment by: cmbecker69 at gmx dot de
Reported by:sagawa at sohgoh dot net
Summary:[Patch] uniqid("prefix", 0) now works under recent
cygwin
Status: Feedback
Type: Feature/Change Request
Package:*General Issues
Operating System: CYGWIN_NT-5.1 1.5.7
PHP Version:4.3.5RC2
Block user comment: N
Private report: N
New Comment:
I have now recompiled PHP 5.4.19 with the patch given above:
$ php -r 'var_dump(uniqid(null, false));'
string(13) "5228be262625a"
Previous Comments:
----
[2013-09-05 13:22:37] cmbecker69 at gmx dot de
I made the following test:
$ uname -a
CYGWIN_NT-5.1 RELIANT 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin
$ php -v
PHP 5.4.19 (cli) (built: Aug 23 2013 19:12:30)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
$ php -r 'var_dump(uniqid(null,false));'
PHP Warning: uniqid(): You must use 'more entropy' under CYGWIN
in Command line code on line 1
Warning: uniqid(): You must use 'more entropy' under CYGWIN
in Command line code on line 1
bool(false)
>From looking at the sources[1], the result is not surprising.
[1] <http://lxr.php.net/xref/PHP_5_4/ext/standard/uniqid.c#63>
<http://lxr.php.net/xref/PHP_5_5/ext/standard/uniqid.c#63>
[2013-07-31 01:39:26] yohg...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2004-02-08 00:40:54] sagawa at sohgoh dot net
Description:
According to cygwin-patches(*1) and ChangeLog(*2), Cygwin's usleep now advances
system clock(gettimeofday).
*1 .. http://sources.redhat.com/ml/cygwin-patches/2003-q3/msg00178.html
*2 ..
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/signal.cc?cvsroot=src#rev1.48
Therefore I can use uniqid safely when more entropy flag is zero, I made a
patch. (but "more entropy flag" is still on by default for backward
compatibility)
Unfortunary cygwin doesn't change version for this change, I apply most recent
change of CYGWIN_VERSION_API_MINOR.
"String functions [tests/strings/001.phpt]" now pass!
--- php-4.3.5RC2/ext/standard/uniqid.c.orig 2003-01-01 01:35:35.0
+0900
+++ php-4.3.5RC2/ext/standard/uniqid.c 2004-02-08 13:01:49.006220800 +0900
@@ -34,6 +34,9 @@
#else
#include
#endif
+#if defined(__CYGWIN__)
+#include
+#endif
#include "php_lcg.h"
#include "uniqid.h"
@@ -66,7 +69,7 @@
}
#if HAVE_USLEEP && !defined(PHP_WIN32)
if (!more_entropy) {
-#if defined(__CYGWIN__)
+#if defined(__CYGWIN__) && (CYGWIN_VERSION_API_MINOR < 91)
php_error_docref(NULL TSRMLS_CC, E_ERROR, "You must use 'more
entropy' under CYGWIN.");
return;
#else
--- php-4.3.5RC2/tests/strings/001.phpt.orig2001-03-21 21:47:46.0
+0900
+++ php-4.3.5RC2/tests/strings/001.phpt 2004-02-08 13:23:53.320491200 +0900
@@ -181,8 +181,8 @@
echo "Testing uniqid: ";
$str = "prefix";
-$ui1 = uniqid($str);
-$ui2 = uniqid($str);
+$ui1 = uniqid($str, 0);
+$ui2 = uniqid($str, 0);
if (strlen($ui1) == strlen($ui2) && strlen($ui1) == 19 && $ui1 != $ui2) {
echo("passed\n");
} else {
Reproduce code:
---
Expected result:
-- cygwin --
prefix4025c46680d100.85790027
prefix4025c466810f81.04902838
prefix4025c466814e0
prefix4025c466818c8
prefix4025c46681cb0
-- linux --
prefix4025c4a472847
prefix4025c4a47289a3.07476264
prefix4025c4a47766a
prefix4025c4a47c487
prefix4025c4a4812a8
Actual result:
--
-- cygwin(NG) --
PHP Fatal error: uniqid(): You must use 'more entropy' under CYGWIN. in
/home/sagawa/uniqid_test.php on line 4
prefix4025c46680d100.85790027
prefix4025c466810f81.04902838
-- linux(OK) --
prefix4025c4a472847
prefix4025c4a47289a3.07476264
prefix4025c4a47766a
prefix4025c4a47c487
prefix4025c4a4812a8
--
Edit this bug report at https://bugs.php.net/bug.php?id=27182&edit=1
Req #27182 [Com]: [Patch] uniqid("prefix", 0) now works under recent cygwin
Edit report at https://bugs.php.net/bug.php?id=27182&edit=1
ID: 27182
Comment by: cmbecker69 at gmx dot de
Reported by:sagawa at sohgoh dot net
Summary:[Patch] uniqid("prefix", 0) now works under recent
cygwin
Status: Feedback
Type: Feature/Change Request
Package:*General Issues
Operating System: CYGWIN_NT-5.1 1.5.7
PHP Version:4.3.5RC2
Block user comment: N
Private report: N
New Comment:
I made the following test:
$ uname -a
CYGWIN_NT-5.1 RELIANT 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin
$ php -v
PHP 5.4.19 (cli) (built: Aug 23 2013 19:12:30)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
$ php -r 'var_dump(uniqid(null,false));'
PHP Warning: uniqid(): You must use 'more entropy' under CYGWIN
in Command line code on line 1
Warning: uniqid(): You must use 'more entropy' under CYGWIN
in Command line code on line 1
bool(false)
>From looking at the sources[1], the result is not surprising.
[1] <http://lxr.php.net/xref/PHP_5_4/ext/standard/uniqid.c#63>
<http://lxr.php.net/xref/PHP_5_5/ext/standard/uniqid.c#63>
Previous Comments:
[2013-07-31 01:39:26] yohg...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.4-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2004-02-08 00:40:54] sagawa at sohgoh dot net
Description:
According to cygwin-patches(*1) and ChangeLog(*2), Cygwin's usleep now advances
system clock(gettimeofday).
*1 .. http://sources.redhat.com/ml/cygwin-patches/2003-q3/msg00178.html
*2 ..
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/signal.cc?cvsroot=src#rev1.48
Therefore I can use uniqid safely when more entropy flag is zero, I made a
patch. (but "more entropy flag" is still on by default for backward
compatibility)
Unfortunary cygwin doesn't change version for this change, I apply most recent
change of CYGWIN_VERSION_API_MINOR.
"String functions [tests/strings/001.phpt]" now pass!
--- php-4.3.5RC2/ext/standard/uniqid.c.orig 2003-01-01 01:35:35.0
+0900
+++ php-4.3.5RC2/ext/standard/uniqid.c 2004-02-08 13:01:49.006220800 +0900
@@ -34,6 +34,9 @@
#else
#include
#endif
+#if defined(__CYGWIN__)
+#include
+#endif
#include "php_lcg.h"
#include "uniqid.h"
@@ -66,7 +69,7 @@
}
#if HAVE_USLEEP && !defined(PHP_WIN32)
if (!more_entropy) {
-#if defined(__CYGWIN__)
+#if defined(__CYGWIN__) && (CYGWIN_VERSION_API_MINOR < 91)
php_error_docref(NULL TSRMLS_CC, E_ERROR, "You must use 'more
entropy' under CYGWIN.");
return;
#else
--- php-4.3.5RC2/tests/strings/001.phpt.orig2001-03-21 21:47:46.0
+0900
+++ php-4.3.5RC2/tests/strings/001.phpt 2004-02-08 13:23:53.320491200 +0900
@@ -181,8 +181,8 @@
echo "Testing uniqid: ";
$str = "prefix";
-$ui1 = uniqid($str);
-$ui2 = uniqid($str);
+$ui1 = uniqid($str, 0);
+$ui2 = uniqid($str, 0);
if (strlen($ui1) == strlen($ui2) && strlen($ui1) == 19 && $ui1 != $ui2) {
echo("passed\n");
} else {
Reproduce code:
---
Expected result:
-- cygwin --
prefix4025c46680d100.85790027
prefix4025c466810f81.04902838
prefix4025c466814e0
prefix4025c466818c8
prefix4025c46681cb0
-- linux --
prefix4025c4a472847
prefix4025c4a47289a3.07476264
prefix4025c4a47766a
prefix4025c4a47c487
prefix4025c4a4812a8
Actual result:
--
-- cygwin(NG) --
PHP Fatal error: uniqid(): You must use 'more entropy' under CYGWIN. in
/home/sagawa/uniqid_test.php on line 4
prefix4025c46680d100.85790027
prefix4025c466810f81.04902838
-- linux(OK) --
prefix4025c4a472847
prefix4025c4a47289a3.07476264
prefix4025c4a47766a
prefix4025c4a47c487
prefix4025c4a4812a8
--
Edit this bug report at https://bugs.php.net/bug.php?id=27182&edit=1
Bug #65548 [Com]: Comparison for DateTimeImmutable doesn't work
Edit report at https://bugs.php.net/bug.php?id=65548&edit=1
ID: 65548
Comment by: cmbecker69 at gmx dot de
Reported by:mail at roland-ramthun dot de
Summary:Comparison for DateTimeImmutable doesn't work
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
It seems that the comparison operators are not overloaded for
DateTimeImmutable objects. Apparently they show the same behavior
as for arbitrary user defined classes.
If my assumption is correct, instead of adding a special treatment
for the comparison operators wrt. DateTimeImmutable objects, it
might be considered to add a magic method __compare(). However,
I'm not sure, if this fits well with type juggling.
Previous Comments:
[2013-08-25 14:03:21] mail at roland-ramthun dot de
Description:
Comparison for DateTimeImmutable doesn't work. The same example with DateTime
objects works.
Test script:
---
$a = new DateTimeImmutable('today');
$b = new DateTimeImmutable('tomorrow');
if ($a < $b) {
print("yay");
}
Expected result:
yay
Actual result:
--
no output
--
Edit this bug report at https://bugs.php.net/bug.php?id=65548&edit=1
Bug #65497 [Opn]: All tests are failing
Edit report at https://bugs.php.net/bug.php?id=65497&edit=1
ID: 65497
User updated by:cmbecker69 at gmx dot de
Reported by:cmbecker69 at gmx dot de
Summary:All tests are failing
Status: Open
Type: Bug
Package:*Compile Issues
Operating System: Cygwin
PHP Version:5.5.2
Block user comment: N
Private report: N
New Comment:
FWIW: PHP 5.4.19 and PHP 5.5.3 show the same behavior.
Previous Comments:
[2013-08-23 11:41:13] cmbecker69 at gmx dot de
The test runner reports:
INI actual : /usr/local/lib/php.ini
More .INIs :
When this file is a copy of the shipped php.ini-developement
resp. php.ini-production (I tried both), all tests are failing.
Through some expermentation I found that the variables_order
setting (which is "GPCS" in both php.ini files) is causing the
tests to fail. It seems to be necessary that "E" is included
on my system.
Through further expermentation I found that the environment
variable PATH is necessary to successfully run the tests.
Adding the following line at the beginning of run-tests.php
was sufficient:
$_ENV['PATH']=getenv('PATH');
My PATH contains nothing special:
/usr/local/bin:/usr/bin/:/cygdrive/c/WINDOWS/system32/:/cygdrive/c/WINDOWS/:/cyg
drive/c/WINDOWS/System32/Wbem/
[2013-08-23 01:21:38] johan...@php.net
So you most likely have another php.ini which is loaded which tries to load a
shared extension which fails.
the test system is supposed to verify PHP wors with "all" *valid*
configurations.
check the ini files the test runner mentions at the top of the output under
"INI actual" and "More .INIs"
--------------------
[2013-08-22 14:43:36] cmbecker69 at gmx dot de
Indeed it is an issue related to the php.ini. When I remove it or
disable it for single tests with -n, most tests succeed (I'll
send a report about the failing tests to the qa-reports list).
According to README.TESTING [Which php.ini is used] it shouldn't
matter which php.ini is used. But both php.ini-production as well
as php.ini-development cause all tests to fail ("error while loading
shared libraries").
However, no errors are reported when running PHP with either of both php.ini
files.
[2013-08-22 08:22:04] yohg...@php.net
You might have linked with incompatible library.
ldd php or ldd libphp5.so too see what are linked.
It may happen during build also.
I recently helped a user who had build problem due to libtool installed under
/usr/local. Explicitly using proper libtool solved the problem.
Look for suspicious errors in build log, too.
[2013-08-22 05:50:07] s...@php.net
This looks like some environment problem. PHP does not load its own shared
libs,
so whatever is going wrong is going wrong either in the compiler or in the
environment. If you're getting this message with tests but not when you run
either -v or -i, the difference may be either php.ini or some environment vars.
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=65497
--
Edit this bug report at https://bugs.php.net/bug.php?id=65497&edit=1
Bug #65497 [Fbk->Opn]: All tests are failing
Edit report at https://bugs.php.net/bug.php?id=65497&edit=1
ID: 65497
User updated by:cmbecker69 at gmx dot de
Reported by:cmbecker69 at gmx dot de
Summary:All tests are failing
-Status: Feedback
+Status: Open
Type: Bug
Package:*Compile Issues
Operating System: Cygwin
PHP Version:5.5.2
Block user comment: N
Private report: N
New Comment:
The test runner reports:
INI actual : /usr/local/lib/php.ini
More .INIs :
When this file is a copy of the shipped php.ini-developement
resp. php.ini-production (I tried both), all tests are failing.
Through some expermentation I found that the variables_order
setting (which is "GPCS" in both php.ini files) is causing the
tests to fail. It seems to be necessary that "E" is included
on my system.
Through further expermentation I found that the environment
variable PATH is necessary to successfully run the tests.
Adding the following line at the beginning of run-tests.php
was sufficient:
$_ENV['PATH']=getenv('PATH');
My PATH contains nothing special:
/usr/local/bin:/usr/bin/:/cygdrive/c/WINDOWS/system32/:/cygdrive/c/WINDOWS/:/cyg
drive/c/WINDOWS/System32/Wbem/
Previous Comments:
[2013-08-23 01:21:38] johan...@php.net
So you most likely have another php.ini which is loaded which tries to load a
shared extension which fails.
the test system is supposed to verify PHP wors with "all" *valid*
configurations.
check the ini files the test runner mentions at the top of the output under
"INI actual" and "More .INIs"
--------------------
[2013-08-22 14:43:36] cmbecker69 at gmx dot de
Indeed it is an issue related to the php.ini. When I remove it or
disable it for single tests with -n, most tests succeed (I'll
send a report about the failing tests to the qa-reports list).
According to README.TESTING [Which php.ini is used] it shouldn't
matter which php.ini is used. But both php.ini-production as well
as php.ini-development cause all tests to fail ("error while loading
shared libraries").
However, no errors are reported when running PHP with either of both php.ini
files.
[2013-08-22 08:22:04] yohg...@php.net
You might have linked with incompatible library.
ldd php or ldd libphp5.so too see what are linked.
It may happen during build also.
I recently helped a user who had build problem due to libtool installed under
/usr/local. Explicitly using proper libtool solved the problem.
Look for suspicious errors in build log, too.
[2013-08-22 05:50:07] s...@php.net
This looks like some environment problem. PHP does not load its own shared
libs,
so whatever is going wrong is going wrong either in the compiler or in the
environment. If you're getting this message with tests but not when you run
either -v or -i, the difference may be either php.ini or some environment vars.
----------------
[2013-08-21 22:40:37] cmbecker69 at gmx dot de
For most development I'm using "normal" Windows builds,
but for some experiments I prefer the Unix toolchain,
so Cygwin comes in handy (I could use a virtual machine,
but it seems a bit heavyweight).
I should have noted in the first place that the compiled
PHP seems to run fine; at least I haven't noticed any issues
yet (neither CLI nor CGI).
basic/001.out:
/home/cmb/php-5.5.2/sapi/cli/php.exe: error while loading
shared libraries: ?: cannot open shared object file: No
such file or directory
The other .out files have the same message (I've checked
only a handful, however).
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=65497
--
Edit this bug report at https://bugs.php.net/bug.php?id=65497&edit=1
Bug #65497 [Com]: All tests are failing
Edit report at https://bugs.php.net/bug.php?id=65497&edit=1
ID: 65497
Comment by: cmbecker69 at gmx dot de
Reported by:cmbecker69 at gmx dot de
Summary:All tests are failing
Status: Open
Type: Bug
Package:*Compile Issues
Operating System: Cygwin
PHP Version:5.5.2
Block user comment: N
Private report: N
New Comment:
Indeed it is an issue related to the php.ini. When I remove it or
disable it for single tests with -n, most tests succeed (I'll
send a report about the failing tests to the qa-reports list).
According to README.TESTING [Which php.ini is used] it shouldn't
matter which php.ini is used. But both php.ini-production as well
as php.ini-development cause all tests to fail ("error while loading
shared libraries").
However, no errors are reported when running PHP with either of both php.ini
files.
Previous Comments:
[2013-08-22 08:22:04] yohg...@php.net
You might have linked with incompatible library.
ldd php or ldd libphp5.so too see what are linked.
It may happen during build also.
I recently helped a user who had build problem due to libtool installed under
/usr/local. Explicitly using proper libtool solved the problem.
Look for suspicious errors in build log, too.
[2013-08-22 05:50:07] s...@php.net
This looks like some environment problem. PHP does not load its own shared
libs,
so whatever is going wrong is going wrong either in the compiler or in the
environment. If you're getting this message with tests but not when you run
either -v or -i, the difference may be either php.ini or some environment vars.
----
[2013-08-21 22:40:37] cmbecker69 at gmx dot de
For most development I'm using "normal" Windows builds,
but for some experiments I prefer the Unix toolchain,
so Cygwin comes in handy (I could use a virtual machine,
but it seems a bit heavyweight).
I should have noted in the first place that the compiled
PHP seems to run fine; at least I haven't noticed any issues
yet (neither CLI nor CGI).
basic/001.out:
/home/cmb/php-5.5.2/sapi/cli/php.exe: error while loading
shared libraries: ?: cannot open shared object file: No
such file or directory
The other .out files have the same message (I've checked
only a handful, however).
[2013-08-21 21:57:46] johan...@php.net
Cygwin is a complicated platform, any reason you're not using "normal" Windows
or some "normal" Unix/linux?
That aside: There shouldn't be any dll's or so's being built. Can you please
check the created .out / .diff files from the tests to see whether the report
any specific error? If they run at all PHP can't be totally broken as the test
runner is using PHP, too. I guess it is some php.ini related error.
----------------
[2013-08-21 21:38:01] cmbecker69 at gmx dot de
Description:
After compiling PHP 5.5.2 on Cygwin[1] all tests
of the accompanying test suite are failing.
This might be related to the shared libraries, which don't seem
to be properly build on Cygwin (.so instead of .dll.a, with a filesize
of less than 1 KB).
[1] $ uname -a
CYGWIN_NT-5.1 RELIANT 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin
Test script:
---
./configure --enable-opcache=no
make
make test
Expected result:
The tests succeed.
Actual result:
--
All tests fail.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65497&edit=1
Bug #65497 [Fbk->Opn]: All tests are failing
Edit report at https://bugs.php.net/bug.php?id=65497&edit=1 ID: 65497 User updated by:cmbecker69 at gmx dot de Reported by:cmbecker69 at gmx dot de Summary:All tests are failing -Status: Feedback +Status: Open Type: Bug Package:Testing related Operating System: Cygwin PHP Version:5.5.2 Block user comment: N Private report: N New Comment: For most development I'm using "normal" Windows builds, but for some experiments I prefer the Unix toolchain, so Cygwin comes in handy (I could use a virtual machine, but it seems a bit heavyweight). I should have noted in the first place that the compiled PHP seems to run fine; at least I haven't noticed any issues yet (neither CLI nor CGI). basic/001.out: /home/cmb/php-5.5.2/sapi/cli/php.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory The other .out files have the same message (I've checked only a handful, however). Previous Comments: [2013-08-21 21:57:46] johan...@php.net Cygwin is a complicated platform, any reason you're not using "normal" Windows or some "normal" Unix/linux? That aside: There shouldn't be any dll's or so's being built. Can you please check the created .out / .diff files from the tests to see whether the report any specific error? If they run at all PHP can't be totally broken as the test runner is using PHP, too. I guess it is some php.ini related error. -------------------- [2013-08-21 21:38:01] cmbecker69 at gmx dot de Description: After compiling PHP 5.5.2 on Cygwin[1] all tests of the accompanying test suite are failing. This might be related to the shared libraries, which don't seem to be properly build on Cygwin (.so instead of .dll.a, with a filesize of less than 1 KB). [1] $ uname -a CYGWIN_NT-5.1 RELIANT 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin Test script: --- ./configure --enable-opcache=no make make test Expected result: The tests succeed. Actual result: -- All tests fail. -- Edit this bug report at https://bugs.php.net/bug.php?id=65497&edit=1
[PHP-BUG] Bug #65497 [NEW]: All tests are failing
From: cmbecker69 at gmx dot de Operating system: Cygwin PHP version: 5.5.2 Package: Testing related Bug Type: Bug Bug description:All tests are failing Description: After compiling PHP 5.5.2 on Cygwin[1] all tests of the accompanying test suite are failing. This might be related to the shared libraries, which don't seem to be properly build on Cygwin (.so instead of .dll.a, with a filesize of less than 1 KB). [1] $ uname -a CYGWIN_NT-5.1 RELIANT 1.7.18(0.263/5/3) 2013-04-19 10:39 i686 Cygwin Test script: --- ./configure --enable-opcache=no make make test Expected result: The tests succeed. Actual result: -- All tests fail. -- Edit bug report at https://bugs.php.net/bug.php?id=65497&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65497&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65497&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65497&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65497&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65497&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65497&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65497&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65497&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65497&r=support Expected behavior: https://bugs.php.net/fix.php?id=65497&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65497&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65497&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65497&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65497&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65497&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65497&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65497&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65497&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65497&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65497&r=mysqlcfg
Bug #65418 [Com]: Neither is_numeric() nor intval() recognize '0b...' strings.
Edit report at https://bugs.php.net/bug.php?id=65418&edit=1
ID: 65418
Comment by: cmbecker69 at gmx dot de
Reported by:brucewlee at verizon dot net
Summary:Neither is_numeric() nor intval() recognize '0b...'
strings.
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.4.0 and later
Block user comment: N
Private report: N
New Comment:
This is a duplicate of <https://bugs.php.net/bug.php?id=64877>
Previous Comments:
[2013-08-08 05:31:27] yohg...@php.net
This is actually a scripting engine problem. Both is_numeric() and intval() end
up calling function that defined in Zend/zend_operators.c. Responsive functions
are not treat binary strings as integer string.
is_numeric() calls
static inline zend_uchar is_numeric_string_ex(const char *str, int length, long
*lval, double *dval, int allow_errors, int *oflow_info)
inval() calls
ZEND_API void convert_to_long_base(zval *op, int base) /* {{{ */
case IS_STRING:
{
char *strval = Z_STRVAL_P(op);
Z_LVAL_P(op) = strtol(strval, NULL, base);
STR_FREE(strval);
}
break;
[2013-08-08 05:11:50] yohg...@php.net
binary format was introduced from 5.4.0.
[2013-08-08 04:36:33] brucewlee at verizon dot net
Description:
Neither is_numeric() nor intval() recognize '0b...' strings.
Test script:
---
Code:
$as = array("0x10", "16", "020", "0b1");
foreach($as as $v) {
echo "The function is_numeric('" . $v . "') returns ";
if (is_numeric($v)) { echo("true"); } else { echo("false"); };
echo ".";
}
Output:
The function is_numeric('0x10') returns true.
The function is_numeric('16') returns true.
The function is_numeric('020') returns true.
The function is_numeric('0b1') returns false.
Code:
$as = array(["0x10", 16], ["16", 10], ["020", 8], ["0b1", 2]);
foreach($as as $v) {
echo "The function intval('" . $v[0] . "', " . $v[1] . ") returns " .
intval($v[0], $v[1]) . ".";
}
Output:
The function intval('0x10', 16) returns 16.
The function intval('16', 10) returns 16.
The function intval('020', 8) returns 16.
The function intval('0b1', 2) returns 0.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65418&edit=1
Bug #65339 [Com]: 08 and 8 are not the same and 09 and 9 are also not the same
Edit report at https://bugs.php.net/bug.php?id=65339&edit=1
ID: 65339
Comment by: cmbecker69 at gmx dot de
Reported by:dondanielsgh at yahoo dot com
Summary:08 and 8 are not the same and 09 and 9 are also not
the same
Status: Open
Type: Bug
Package:PHP options/info functions
Operating System: windows
PHP Version:5.5.1
Block user comment: N
Private report: N
New Comment:
| the results should be correct.
Actually the results are correct. 07, 08 and 09 are treated as
octal integers, and the documentation on integers
(<http://www.php.net/manual/en/language.types.integer.php>) states:
| If an invalid digit is given in an octal integer (i.e. 8 or 9),
| the rest of the number is ignored.
Previous Comments:
[2013-07-25 20:42:49] dondanielsgh at yahoo dot com
Description:
$x = 07;
if($x == 7){
echo 'correct';
}else{
echo 'they are not the same';
}
$x = 08;
if($x == 8){
echo 'correct';
}else{
echo 'they are not the same';
}
$x = 09;
if($x == 9){
echo 'correct';
}else{
echo 'they are not the same';
}
Test script:
---
$x = 07;
if($x == 7){
echo 'correct';
}else{
echo 'they are not the same';
}
$x = 08;
if($x == 8){
echo 'correct';
}else{
echo 'they are not the same';
}
$x = 09;
if($x == 9){
echo 'correct';
}else{
echo 'they are not the same';
}
Expected result:
$x = 08;
if($x == 8){
echo 'correct';
}else{
echo 'they are not the same';
}
$x = 09;
if($x == 9){
echo 'correct';
}else{
echo 'they are not the same';
}
the results should be correct.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65339&edit=1
Bug #65229 [Com]: Fatal error using class Inheritance
Edit report at https://bugs.php.net/bug.php?id=65229&edit=1
ID: 65229
Comment by: cmbecker69 at gmx dot de
Reported by:odiel dot leon at gmail dot com
Summary:Fatal error using class Inheritance
Status: Open
Type: Bug
Package:Class/Object related
Operating System: Ubuntu 12.04.1 LTS
PHP Version:5.4.17
Block user comment: N
Private report: N
New Comment:
This is not a bug, as it is clearly documented on
<http://www.php.net/manual/en/language.oop5.inheritance.php>:
| Unless autoloading is used, then classes must be defined before
| they are used. If a class extends another, then the parent
| class must be declared before the child class structure. This
| rule applies to classes that inherit other classes and interfaces.
Previous Comments:
[2013-07-09 21:21:55] odiel dot leon at gmail dot com
Description:
PHP is generating a fatal error when a class that inherit from another is
getting instantiated and these classes are defined after being instantiated.
If the class does not inherit PHP run the code without errors.
Test script:
---
hi();
class Aa extends Bb
{
}
class Bb
{
public function hi()
{
echo('hi Aa');
}
}
Expected result:
hi Aa
Actual result:
--
PHP Fatal error: Class 'Aa' not found in /home/www/test.php on line 3
--
Edit this bug report at https://bugs.php.net/bug.php?id=65229&edit=1
Bug #65170 [Com]: SPLHeap next() removes current node
Edit report at https://bugs.php.net/bug.php?id=65170&edit=1 ID: 65170 Comment by: cmbecker69 at gmx dot de Reported by:mark at lange dot demon dot co dot uk Summary:SPLHeap next() removes current node Status: Open Type: Bug Package:SPL related Operating System: All PHP Version:5.3.26 Block user comment: N Private report: N New Comment: It seems to me this is rather a documentation issue (it should be noted that SplHeap::next() discards the top of the heap), as the documentation of SplHeap::rewind() shows. And that is consistent with the implementation, where spl_ptr_heap_delete_top() is explicitely called. Previous Comments: [2013-06-30 21:36:48] mark at lange dot demon dot co dot uk Description: When iterating through an SPLHeap, each node is removed from the heap as you loop through to the next node. Investigation has suggested that it is the next() method that removes the current node before moving to the next. Test script: --- https://gist.github.com/MarkBaker/5896053 Expected result: There are 7 cities in the heap FROM NORTH TO SOUTH Newcastle upon Tyne +54.9833 -1.5833 Leeds+53.8100 -1.5500 Manchester +53.4800 -2.2400 Liverpool+53.4167 -3. Birmingham +52.4800 -1.9100 London +51.5171 -0.1062 Bristol +51.4600 -2.6000 There are 7 cities in the heap There should be the same number of city nodes in the heap after iterating through as there were before. Actual result: -- There are 7 cities in the heap FROM NORTH TO SOUTH Newcastle upon Tyne +54.9833 -1.5833 Leeds+53.8100 -1.5500 Manchester +53.4800 -2.2400 Liverpool+53.4167 -3. Birmingham +52.4800 -1.9100 London +51.5171 -0.1062 Bristol +51.4600 -2.6000 There are 0 cities in the heap However, there a 0 city nodes left in the heap after iterating through them. -- Edit this bug report at https://bugs.php.net/bug.php?id=65170&edit=1
Bug #65141 [Com]: filter_var() validates URL with two http:// as valid
Edit report at https://bugs.php.net/bug.php?id=65141&edit=1
ID: 65141
Comment by: cmbecker69 at gmx dot de
Reported by:demtheman at yahoo dot com
Summary:filter_var() validates URL with two http:// as valid
Status: Open
Type: Bug
Package:URL related
Operating System: Windows 7 64-bit
PHP Version:5.3.26
Block user comment: N
Private report: N
New Comment:
As Thomas Lahn pointed out in comp.lang.php
(<7348494.gbytuhr...@pointedears.de>)
the mentioned URI (there was used a slightly different URI,
but that doesn't matter in this case, as the productions can be adapted)
is actually valid according to RFC 2396.
Previous Comments:
[2013-06-27 20:56:48] cmbecker69 at gmx dot de
According to RFC 2396 Appendix A the example URI doesn't seem to be valid,
even if it passes the regular expression given in Appendix B.
However, filter_var($var, FILTER_VALIDATE_URL) is based on parse_url().
parse_url('http://http://example.com') evaluates to:
Array
(
[scheme] => http
[host] => http
[path] => //example.com
)
This is apparently wrong in this case according to RFC 2396; neither an
abs_path
nor a rel_path must start with a double slash.
[2013-06-27 03:39:05] demtheman at yahoo dot com
Description:
I used filter_var() to validate the URL http://http://www.google.com (as test
URL), however it seems to see it as valid which in fact is wrong. Refer to my
SO
question http://stackoverflow.com/questions/17333612/filter-var-accepts-invalid-
url
Test script:
---
$website = "http://http://www.google.com";;
echo filter_var($website, FILTER_VALIDATE_URL);
Expected result:
The filter_var() should return FALSE.
Actual result:
--
The filter_var() returns the filtered data.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65141&edit=1
Bug #65141 [Com]: filter_var() validates URL with two http:// as valid
Edit report at https://bugs.php.net/bug.php?id=65141&edit=1
ID: 65141
Comment by: cmbecker69 at gmx dot de
Reported by:demtheman at yahoo dot com
Summary:filter_var() validates URL with two http:// as valid
Status: Open
Type: Bug
Package:URL related
Operating System: Windows 7 64-bit
PHP Version:5.3.26
Block user comment: N
Private report: N
New Comment:
According to RFC 2396 Appendix A the example URI doesn't seem to be valid,
even if it passes the regular expression given in Appendix B.
However, filter_var($var, FILTER_VALIDATE_URL) is based on parse_url().
parse_url('http://http://example.com') evaluates to:
Array
(
[scheme] => http
[host] => http
[path] => //example.com
)
This is apparently wrong in this case according to RFC 2396; neither an
abs_path
nor a rel_path must start with a double slash.
Previous Comments:
[2013-06-27 03:39:05] demtheman at yahoo dot com
Description:
I used filter_var() to validate the URL http://http://www.google.com (as test
URL), however it seems to see it as valid which in fact is wrong. Refer to my
SO
question http://stackoverflow.com/questions/17333612/filter-var-accepts-invalid-
url
Test script:
---
$website = "http://http://www.google.com";;
echo filter_var($website, FILTER_VALIDATE_URL);
Expected result:
The filter_var() should return FALSE.
Actual result:
--
The filter_var() returns the filtered data.
--
Edit this bug report at https://bugs.php.net/bug.php?id=65141&edit=1
Bug #64890 [Com]: strrpos with negative offset incorrect results
Edit report at https://bugs.php.net/bug.php?id=64890&edit=1
ID: 64890
Comment by: cmbecker69 at gmx dot de
Reported by:me at rouvenwessling dot de
Summary:strrpos with negative offset incorrect results
Status: Open
Type: Bug
Package:Strings related
Operating System: OS X
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
The issue occurs for negative offsets,
when the length of the needle is less than
or equal to the absolute value of the offset.
The cause seems to be in ext/standard/string.c line 1958:
e = haystack + haystack_len + offset;
This lets e reference one character further to the right
than it actually should. Changing this line to:
e = haystack + haystack_len + offset - 1;
fixes the issue and gives the expected result for the test script.
Previous Comments:
[2013-05-21 17:53:36] me at rouvenwessling dot de
Description:
Apparently the offset in strrpos doesn't work right if it's the same as the
needle
length.
Test script:
---
$result = strrpos('Internationalization', 'n', -1);
var_dump($result);
Expected result:
int(10)
Actual result:
--
int(19)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64890&edit=1
Bug #64754 [Com]: pathinfo bug handling extra "."
Edit report at https://bugs.php.net/bug.php?id=64754&edit=1
ID: 64754
Comment by: cmbecker69 at gmx dot de
Reported by:jia dot cheng dot wu at gmail dot com
Summary:pathinfo bug handling extra "."
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: WINDOWS 7
PHP Version:5.3.24
Block user comment: N
Private report: N
New Comment:
pathinfo() is meant to return information about a *file path*,
not an URL. The latter can be accomplished with parse_url().
Furthermore the documentation states:
| If the path has more than one an extension,
| PATHINFO_EXTENSION returns only the last one
| and PATHINFO_FILENAME only strips the last one.
| (see first example below).
According to that the actual result is correct.
Previous Comments:
[2013-05-07 19:13:24] mail+php at requinix dot net
pathinfo() is for filenames. Use parse_url() for URLs.
[2013-05-02 05:45:38] jia dot cheng dot wu at gmail dot com
Description:
Array returned by function pathinfo() contains wrong values when extra "." is
introduced in the parameter, even though "." is a valid character of a query
string.
Test script:
---
Expected result:
test_url:/test.php?q=hello+this+is+a+test+1.0
array(4) {
["dirname"]=>
string(1) "\"
["basename"]=>
string(35) "test.php?q=hello+this+is+a+test+1.0"
["extension"]=>
string(26) "q=hello+this+is+a+test+1.0"
["filename"]=>
string(4) "test"
}
Actual result:
--
test_url:/test.php?q=hello+this+is+a+test+1.0
array(4) {
["dirname"]=>
string(1) "\"
["basename"]=>
string(35) "test.php?q=hello+this+is+a+test+1.0"
["extension"]=>
string(1) "0"
["filename"]=>
string(33) "test.php?q=hello+this+is+a+test+1"
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=64754&edit=1
Bug #64874 [Com]: json_decode handles whitespace and case-sensitivity incorrectly
Edit report at https://bugs.php.net/bug.php?id=64874&edit=1
ID: 64874
Comment by: cmbecker69 at gmx dot de
Reported by:chrivers at iversen-net dot dk
Summary:json_decode handles whitespace and case-sensitivity
incorrectly
Status: Open
Type: Bug
Package:JSON related
Operating System: All
PHP Version:5.4.15
Block user comment: N
Private report: N
New Comment:
RFC 4627[1] also states in section 2:
| A JSON text is a serialized object or array.
|
|JSON-text = object / array
According to that definition the $json argument of examples 1-3
is not a valid JSON-text.
Furthermore:
json_decode('true ');
var_dump(json_last_error() === JSON_ERROR_SYNTAX);
prints:
bool(true)
So the returned NULL is actually correct according to the documentation.
[1] <http://www.ietf.org/rfc/rfc4627.txt>
Previous Comments:
[2013-05-17 21:48:29] chrivers at iversen-net dot dk
Description:
There are 2 problems with the json_decode function.
1) It only sometimes disregards whitespace
The RFC clearly says:
"""Insignificant whitespace is allowed before or after any of the six
structural
characters."""
2) It only sometimes enforces lowercase-ness of identifiers
The RFC clearly says:
"""The literal names MUST be lowercase. No other literal names are allowed."""
The test script demonstrates this
Test script:
---
Expected result:
true * 5
Actual result:
--
bool(true)
bool(false)
bool(false)
bool(true)
bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64874&edit=1
Bug #52950 [Com]: Wrong implicit conversion of strings containing hexadecimal numbers to int
Edit report at https://bugs.php.net/bug.php?id=52950&edit=1 ID: 52950 Comment by: cmbecker69 at gmx dot de Reported by:confik at gmail dot com Summary:Wrong implicit conversion of strings containing hexadecimal numbers to int Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux 2.6.32 Ubuntu 10.04/i686 PHP Version:5.3.3 Block user comment: N Private report: N New Comment: IMO the behavior of the implicit type juggling is correct, and the result of the explicit type cast is erroneous in this regard. Anyway, both results should match. Previous Comments: [2010-09-29 10:49:25] confik at gmail dot com Description: If string contains hexadecimal number, such as '0x05' it correctly explicitly casts to integer(resulting zero): php > var_dump((int) '0x05'); int(0) but incorrectly casts implicitly (resulting its value, 5) php > var_dump(1 * '0x05'); int(5) Same for floats: php > var_dump((float) '0xff'); float(0) php > var_dump(1 * '0xff'); float(1099511627775) P.S.: Tests were made on x86 (i686) Linux machine. Test script: --- https://bugs.php.net/bug.php?id=52950&edit=1
Req #41985 [Com]: rename doesn't work
Edit report at https://bugs.php.net/bug.php?id=41985&edit=1 ID: 41985 Comment by: cmbecker69 at gmx dot de Reported by:marc dot bau at gmx dot net Summary:rename doesn't work Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Windows PHP Version:5.2.3 Block user comment: N Private report: N New Comment: This issue is solved since PHP 5.3.0 (released 2009-06-30). rename() works atomic on Windows due to the use of MoveFileEx(..., ..., MOVEFILE_REPLACE_EXISTING) (see virtual_rename() in TSRM/tsrm_virtual_cwd.c resp. VCWD_RENAME() in TSRM/tsrm_virtual.cwd.h). So this issue can be closed. Previous Comments: [2009-12-08 06:10:18] rainmanhhh at tom dot com rename should be remake to copy + unlink to keep php do the same behavior on windows & *nix [2007-07-14 12:58:22] marc dot bau at gmx dot net Well, if this rename is not possible atomically (how bad this ever is), i think PHP should handle the copy/unlink logic in background if i use "rename()". I simply don't like to think about possible platform dependencies (i don't know anything about) and hack around in a bad way that additional produce an error with "E_ALL & ~E_NOTICE" i cannot circumvent. [2007-07-14 10:35:16] der...@php.net I actually agree with that... however, it's not possible to do this atomically on windows if the file you're moving to exists. The only option is to unlink() the target and then do the rename() but that leaves a race condition. I don't think that is solvable on Windows. [2007-07-13 20:57:49] marc dot bau at gmx dot net Do you know how this works on *nix systems? Well i will tell you - it will *move* the "new file" over the "old file" in an atomic rename. This is what PHP needs to handle on Windows, too. I don't need any extras on *nix to rename. And PHP internal command should work platform independent. This bug should be fixed to make sure the code runs on windows in the *same way* as it does on *nix systems. What is so difficult to understand about this? Writing write code once, *run everywhere* is not possible with this bug. [2007-07-13 20:48:09] tony2...@php.net Please open a dictionary and translate the error message: PHP Warning: rename(C:\temp\tmp_file.txt.new,C:\temp\tmp_file.txt): File exists in C:\Temp\rename-test.php on line 2 It says FILE EXISTS, don't you see it? Please do NOT reopen the report again. Thank you. 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=41985 -- Edit this bug report at https://bugs.php.net/bug.php?id=41985&edit=1
