Bug #52861 [Opn->Csd]: unset failes with ArrayObject and deep arrays
Edit report at https://bugs.php.net/bug.php?id=52861&edit=1 ID: 52861 Updated by: s...@php.net Reported by:mep_eisen at web dot de Summary:unset failes with ArrayObject and deep arrays -Status: Open +Status: Closed Type: Bug Package:SPL related Operating System: Windows Vista 64 PHP Version:5.3.3 -Assigned To: +Assigned To:stas Block user comment: N Private report: N New Comment: The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. merged as 61099f85857193c223dd62b0c5302507a77cf0ab Previous Comments: [2011-11-18 13:49:14] nemo at ikkoku dot de One can still use unset if one writes: --- >8 --- $a = ArrayObject(Array('foo' => Array('bar' => 1))); // Won't work ($a['foo']['bar'] is still 1) // Also a notice is displayed: PHP Notice: Indirect modification of // overloaded element of ArrayObject has no effect in php shell code on line ... var_dump($a); unset($a['foo']['bar']); var_dump($a); // This works var_dump($a); $v =& $a['foo']; unset($v['bar']); var_dump($a); // This also works //$v =& $a['foo']['bar']; //unset($v); --- 8< --- [2011-01-07 12:37:52] auke at muze dot nl Just checked with php 5.3.3 and there the code runs as expected, so at least setting works with a nested array. For the record I tried the original bugreport code as well and got the same result, on a linux system, 64 bits (debian), but also this notice: PHP Notice: Indirect modification of overloaded element of ArrayObject has no effect in /var/www/test/test.php on line 22 So at least PHP is honest in that it doesn't work :) [2011-01-07 12:07:34] auke at muze dot nl I found a workaround for the problem that suddenly the parent object has any property you try to access and has it filled with the previously set array. If the containing object has its own __get() method which always returns NULL, the object is safe again. So this code works as expected: class IWouldLikeToPointOutABug { function __get( $name ) { return NULL; } } $buggy = new IWouldLikeToPointOutABug(); $buggy->bug = new ArrayObject( ); $buggy->bug['foo']['bar'] = true; echo "This looks normal\r\n"; var_dump( $buggy ); echo "This should be NULL\r\n"; var_dump( $buggy->thisIsNotHere ); One drawback is that you cannot assign properties by reference anymore because you're now using the __get() overloading method. This does not fix the original bug where unsetting fails. BTW. Our original workaround involved creating our own arrayobject by implementing all the array interfaces, but that will not work either. When you do this: $arrayobject['unsetkey']['key'] = $value; The offsetSet method is never called for 'unsetKey', just the offsetGet. So there is no way to implement the correct behaviour. [2011-01-05 18:51:51] auke at muze dot nl It's worse than this, ArrayObject gets confused on where to put the data and mangles any containing object: test script: class IWouldLikeToPointOutABug { } $buggy = new IWouldLikeToPointOutABug(); $buggy->bug = new ArrayObject( ); $buggy->bug['foo']['bar'] = true; echo "This looks normal\r\n"; var_dump( $buggy ); echo "This should be NULL\r\n"; var_dump( $buggy->thisIsNotHere ); Results in: This looks normal object(IWouldLikeToPointOutABug)#1 (1) { ["bug"]=> object(ArrayObject)#2 (0) { } } This should be NULL array(1) { ["bar"]=> bool(true) } [2010-09-16 17:23:11] mep_eisen at web dot de Description: Using deep arrays unset itself or ArrayObject misbehaves. It silently does nothing. The problem lies in iteration 3 that mixes ArrayObject and classic arrays. Test script: --- echo "iteration1\n"; $arr = new ArrayObject(); $arr['foo'] = new ArrayObject(); $arr['foo']['bar'] = true; unset($arr['foo']['bar']); var_dump($arr); echo "iteration2\n"; $arr = array(); $arr['foo']['bar'] = true; unset($arr['foo']['bar']); var_dump($arr); echo "iteration3\n"; $arr = new ArrayObject(); $arr['foo']['bar'] = true; unset($arr['foo']['bar']); var_dump($arr); Expected result: -
Bug #64258 [Com]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 Comment by: veillard at redhat dot com Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: just to point out that xmlTextReaderSetup is not part of libxml2 ABI, nor on current version nor on 2.6.26. thinkpad:~/XML -> grep xmlTextReaderSetup doc/libxml2-api.xml thinkpad:~/XML -> [root@test-rhel55 ~]# gunzip -c /usr/share/doc/libxml2-devel-2.6.26/libxml2-api.xml.gz | grep xmlTextReaderSetup [root@test-rhel55 ~]# it would be good if PHP didn't use name which looks like that they are coming from libxml2 even if they are possibly wrappers around libxml2 functions. Previous Comments: [2013-02-22 01:56:19] spamik at yum dot pl I would guess that mere presence of --with-mcrypt on configure breaks linking to custom libxml2 directory (--with-libxml-dir=/usr/libxml2-2.9.0/) and it defaults to system /usr/lib64 (and there is distro standard old libxml2 there which break things). [2013-02-22 01:38:34] spamik at yum dot pl also during make install (php) i see ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) /root/naox/php-5.3.21/sapi/cli/php: /usr/lib64/libxml2.so.2: no version information available (required by /root/naox/php-5.3.21/sapi/cli/php) I did not linked to usr/lib64/libxml2.so.2 !! Some error in linking (but only when mcrypt is present) [2013-02-22 01:23:02] spamik at yum dot pl >>Problem appears when compiling with mcrypt and extension (and libxml2 2.9)<< Package libmcrypt-devel-2.5.8-4.el5.centos.x86_64 already installed and latest version ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt make install datadata'; $xml->XML($xmldata); ?> /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup I've also tried compiling libmcrypt from source - no changes. ./configure --prefix=/usr/libmcrypt-2.5.8 --disable-posix-threads make install ./configure '--prefix' '/usr/share/php-5.3.21' --with-libxml-dir=/usr/libxml2- 2.9.0/ '--with-mcrypt=/usr/libmcrypt-2.5.8' sill does not work (it works wit
Bug #64294 [Com]: date conversion problem when dst present
Edit report at https://bugs.php.net/bug.php?id=64294&edit=1 ID: 64294 Comment by: mail+php at requinix dot net Reported by:ybrigant at gmail dot com Summary:date conversion problem when dst present Status: Open Type: Bug Package:Date/time related Operating System: linux debian PHP Version:5.3.22 Block user comment: N Private report: N New Comment: 01:00 UTC that is, so 02:00 Europe/Paris. Previous Comments: [2013-02-27 01:26:11] mail+php at requinix dot net DST in Europe ends at 2013-10-27 01:00. By the way, Unix timestamps don't have timezones. [2013-02-25 10:42:18] ybrigant at gmail dot com Sorry, I forgot to add that timestamp provided is in utc timezone. [2013-02-25 09:55:35] ybrigant at gmail dot com Description: COnversion of an utc timestamp to a date in a scpecific timezone, ie EUrope/Paris where we have dst activated in the date example... Test script: --- $timestamp = 1382954400; $date = new \DateTime('@'.$timestamp); $tz = new \DateTimeZone('Europe/Paris'); $date->setTimezone($tz); return $date->format(Y-m-d H:i'); Expected result: 2013-10-28 12:00 Actual result: -- 2013-10-28 11:00 -- Edit this bug report at https://bugs.php.net/bug.php?id=64294&edit=1
Bug #64294 [Com]: date conversion problem when dst present
Edit report at https://bugs.php.net/bug.php?id=64294&edit=1 ID: 64294 Comment by: mail+php at requinix dot net Reported by:ybrigant at gmail dot com Summary:date conversion problem when dst present Status: Open Type: Bug Package:Date/time related Operating System: linux debian PHP Version:5.3.22 Block user comment: N Private report: N New Comment: DST in Europe ends at 2013-10-27 01:00. By the way, Unix timestamps don't have timezones. Previous Comments: [2013-02-25 10:42:18] ybrigant at gmail dot com Sorry, I forgot to add that timestamp provided is in utc timezone. [2013-02-25 09:55:35] ybrigant at gmail dot com Description: COnversion of an utc timestamp to a date in a scpecific timezone, ie EUrope/Paris where we have dst activated in the date example... Test script: --- $timestamp = 1382954400; $date = new \DateTime('@'.$timestamp); $tz = new \DateTimeZone('Europe/Paris'); $date->setTimezone($tz); return $date->format(Y-m-d H:i'); Expected result: 2013-10-28 12:00 Actual result: -- 2013-10-28 11:00 -- Edit this bug report at https://bugs.php.net/bug.php?id=64294&edit=1
Bug #61354 [Com]: htmlentities and htmlspecialchars doesn't respect the default_charset
Edit report at https://bugs.php.net/bug.php?id=61354&edit=1 ID: 61354 Comment by: rudibr at gmail dot com Reported by:hufeng1987 at gmail dot com Summary:htmlentities and htmlspecialchars doesn't respect the default_charset Status: Not a bug Type: Bug Package:Strings related Operating System: Linux/Windows/ PHP Version:5.4.0 Block user comment: N Private report: N New Comment: What about my third-party modules? Should I change their code as well? Do I now need to verify and manually alter code on third-party modules everytime I upgrade or install them? If Im using a component with protected code, do I need to go trough their support staff and wait for a correction? What if they provide no reliable support or customization, am I now being encouraged to hack and crack in the source code just so I can fix this? It is easy , even redundant , and absolutely justfiable to create a new ini setting to control this behavior, that I feel a little bit offended by the current attitude of php developers over this issue. I also feel a little bit offended because the guy who is responsible for this change EXPLICITLY stated that the change to UTF-8 defaulting have nothing to do with security. It just sounded like a "better default", according to the developer. Hardly a seriously thought-trough consideration. This is becoming quite a sad state of affairs. I guess I will have to consider moving on from php if it comes to that. Previous Comments: [2013-01-27 17:32:18] kstirn at gmail dot com It will soon be a year since the release of PHP 5.4 and there still is no easy way (read: a global PHP setting) to overcome this huge backwards-incompatibility. PHP developers, I understand the security concerns, but please don't be so stubborn and give us an option to set a default setting without having to modify *all* legacy code to work with 5.4. Your action (or lack thereof) is producing the opposite results of desired - instead of moving to PHP 5.4, thousands of servers (including several we own) will stay with 5.3.x even after end of life cycle in March 2013. *Fact* A simple global setting (an optional php.ini value) would solve the issue for thousands of users while addressing security issues by explicitly defining the default charset to be used by affected functions - all without having to rewrite existing code. PHP team please do reconsider this and help everyone not using UTF-8 move to PHP 5.4. Thank you! [2013-01-05 17:39:04] x dot bazilio at gmail dot com Ok. If i did not set defautlt time zone, i get E_WARNING. Let us set default encoding for htmlspecialchars. It is not posible to persuade developers of Drupal, joomla, wordpress, bitrix, ets., and developers of modules for that CMS to rewrite their code. I wrote to tech support of bitrix (russian cms). They said that i must use PHP 5.3.x. They not going to rewrite code. [2013-01-05 16:05:31] leaflet at leafok dot com I understand your consideration. Maybe a global configuration in PHP.ini or page lifecycle set function could be provided for encoding setting of these functions. Developers would be glad to handle this setting centrally by a include header file for each pages. [2013-01-05 15:17:56] ras...@php.net I have explained that a few times. We can't default it automatically because the encoding may not match the output encoding. Only the developer knows that. If we did that automatically it would break even more sites. The sites where the encodings differ need to set it explicitly. [2013-01-05 09:54:44] hufeng1987 at gmail dot com pass null and empty string that could improve security? no sense.. 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=61354 -- Edit this bug report at https://bugs.php.net/bug.php?id=61354&edit=1
Req #45543 [Com]: DateTime::setTimezone can not set timezones without ID
Edit report at https://bugs.php.net/bug.php?id=45543&edit=1 ID: 45543 Comment by: rrollins at caltech dot edu Reported by:tj at systisoft dot com Summary:DateTime::setTimezone can not set timezones without ID Status: Assigned Type: Feature/Change Request Package:Date/time related Operating System: All PHP Version:5.3CVS-2008-07-17 (CVS) Assigned To:derick Block user comment: N Private report: N New Comment: I'm getting this warning when trying to set a DateTime's timezone to "America/Los_Angeles". I don't know what an ID is in this context, but surely America/Los_Angeles has one... right? I'm using PHP 5.3.21 on OSX Mountain Lion. Previous Comments: [2013-01-02 20:11:57] info at strictcoding dot co dot uk Still the same in PHP 5.4.10. This bug is more than 4 years old, could it be looked into? [2011-01-08 19:56:01] wrzasq at gmail dot com I confirm the same on PHP 5.3.3, Debian 64bit. [2009-06-29 16:25:01] scott at crisscott dot com I was able to reproduce this with PHP 5.2.9 from the commandline. php -v PHP 5.2.9 (cli) (built: May 1 2009 13:47:24) $> php -r '$d = new DateTime("2009-01-01 00:00:00+0400"); $d->setTimezone($d->getTimezone());' [2008-07-17 14:34:47] tj at systisoft dot com Description: If you set a time zone for a DateTime via DateTime::setTimeZone() and that time zone has no ID you get an error message and the time zone will not be set. This can lead to problems if you have two DateTime objects from a source you do not control and want to format the second DateTime object in the same time zone as the first. Reproduce code: --- $d1 = new DateTime('2008-01-01 12:00:00 +02:00'); $d2 = new DateTime('2008-01-01 12:00:00 UTC'); echo $d1->format(DATE_ISO8601), PHP_EOL; echo $d2->format(DATE_ISO8601), PHP_EOL; $d2->setTimeZone($d1->getTimeZone()); echo $d1->format(DATE_ISO8601), PHP_EOL; echo $d2->format(DATE_ISO8601), PHP_EOL; Expected result: 2008-01-01T12:00:00+0200 2008-01-01T12:00:00+ 2008-01-01T12:00:00+0200 2008-01-01T14:00:00+0200 Actual result: -- 2008-01-01T12:00:00+0200 2008-01-01T12:00:00+ PHP Warning: DateTime::setTimezone(): Can only do this for zones with ID for now in /Users/tobias/test.php on line 5 Warning: DateTime::setTimezone(): Can only do this for zones with ID for now in /Users/tobias/test.php on line 5 2008-01-01T12:00:00+0200 2008-01-01T12:00:00+ [2008-07-17 13:07:47] tj at systisoft dot com Description: if you set a time zone for a DateTime via DateTime::setTimeZone() and that time zone has no ID you get an error message and the time zone will not be set. This can lead to Problems if you have two DateTime objects from a surce you do not control and want to format the secont DateTime object in the same time zone as the first. Reproduce code: --- $d1 = new DateTime('2008-01-01 12:00:00 +02:00'); $d2 = new DateTime('2008-01-01 12:00:00 UTC'); echo $d1->format(DATE_ISO8601), PHP_EOL; echo $d2->format(DATE_ISO8601), PHP_EOL; $d2->setTimeZone($d1->getTimeZone()); echo $d1->format(DATE_ISO8601), PHP_EOL; echo $d2->format(DATE_ISO8601), PHP_EOL; Expected result: 2008-01-01T12:00:00+0200 2008-01-01T12:00:00+ 2008-01-01T12:00:00+0200 2008-01-01T14:00:00+0200 Actual result: -- 2008-01-01T12:00:00+0200 2008-01-01T12:00:00+ PHP Warning: DateTime::setTimezone(): Can only do this for zones with ID for now in /Users/tobias/test.php on line 5 Warning: DateTime::setTimezone(): Can only do this for zones with ID for now in /Users/tobias/test.php on line 5 2008-01-01T12:00:00+0200 2008-01-01T12:00:00+ -- Edit this bug report at https://bugs.php.net/bug.php?id=45543&edit=1
Req #51254 [Com]: Use internal crypt() only for algorithms needed
Edit report at https://bugs.php.net/bug.php?id=51254&edit=1 ID: 51254 Comment by: iamguinness at gmail dot com Reported by:ondrej at sury dot org Summary:Use internal crypt() only for algorithms needed Status: Open Type: Feature/Change Request Package:*Encryption and hash functions Operating System: Linux PHP Version:5.3.2 Block user comment: N Private report: N New Comment: I was wondering if the problem that "php at rapsys dot eu" reported is going to be fixed. I had the same issue with a custom build on Ubuntu and had to drop this patch. Since it's almost three years old know, I'm just wondering if anyone has bothered to dig deeper into this problem. I'm afraid I don't have the skills to do so... Previous Comments: [2011-03-28 16:37:47] ondrej at sury dot org Hi, the issue is little bit more complicated than adding defined() around the statements. When compiling with --enable-maintainer-zts some header files are included in a way that crypt_r and struct crypt_data is unknown and the compilation fail. Unless you are willing to dig deeper, you can just drop the patch for your custom build. [2011-03-28 15:12:41] php at rapsys dot eu I had a poblem with this patch in debian/ubuntu packages. With this patch the build with --enable-maintainer-zts the ubuntu php5_5.3.2-1ubuntu4.7 package. The problem seems to comes from #if used instead of #ifdef and incorrectly defined strings by your patch. Here is the build log : /home//php/php5-5.3.2/ext/standard/crypt.c:150:27: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:190:27: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:201:3: warning: #warning Using system MD5 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:202:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:214:3: warning: #warning Using system SHA512 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:215:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:227:3: warning: #warning Using system SHA256 crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:228:28: error: #if with no expression /home//php/php5-5.3.2/ext/standard/crypt.c:258:3: warning: #warning Using PHP BlowFish crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:272:3: warning: #warning Using PHP extended DES crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:279:3: warning: #warning Using system standard DES crypt function, which is OK on Debian system /home//php/php5-5.3.2/ext/standard/crypt.c:280:28: error: #if with no expression make[1]: *** [ext/standard/crypt.lo] Error 1 make[1]: Leaving directory `/home//php/php5-5.3.2/apache2-build' make: *** [build-apache2-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1340: dpkg-buildpackage -rfakeroot -D -us -uc failed [2010-03-24 17:02:06] ondrej at sury dot org Hi Pierre, had a time to review this patch and provide a detailed explanation? Ondrej [2010-03-12 11:24:42] paj...@php.net Not sure I agree with these changes, they are not supposed to be valid. I don't have the time now to reply with a detailed explanation but we will do it asap. [2010-03-12 10:15:46] ondrej at sury dot org Hi, if you apply my patch, you'll need to apply the fix_crypt_unit_tests.patch, since I have fixed some routines, which you checked in those unit tests. 1. if you use '_' as a first character of the salt, but the salt is not 9 characters long => STD_DES is used. 2. if you use 00-03 or 32-39 as count in blowfish => STD_DES is used (as documented). 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=51254 -- Edit this bug report at https://bugs.php.net/bug.php?id=51254&edit=1
Bug #53035 [Com]: finfo_file() returns incorrect mimetype
Edit report at https://bugs.php.net/bug.php?id=53035&edit=1 ID: 53035 Comment by: stepan dot stepanov at gmail dot com Reported by:stuart at horuskol dot net Summary:finfo_file() returns incorrect mimetype Status: Feedback Type: Bug Package:Filesystem function related Operating System: Linux/Ubuntu 10.04 PHP Version:Irrelevant Block user comment: N Private report: N New Comment: PHP fileinfo library = 1.0.5-dev Previous Comments: [2013-02-25 18:37:09] paj...@php.net no, I meant the file/fileinfo library on your system. "file" and php does not share the same version. [2013-02-25 15:57:31] stepan dot stepanov at gmail dot com Do you mean version of PHP ? PHP 5.3.19 (cli) [2013-02-25 15:55:23] paj...@php.net Which version do you use on this system? We may need to update the bundled database or library. [2013-02-25 14:59:42] stepan dot stepanov at gmail dot com Command line "file" programm shows the right result. Though php reports wrong one. CentOS release 5.8 See details below: $ file -i char2.csv char2.csv: text/plain; charset=us-ascii $ file -i char.csv char.csv: text/plain; charset=us-ascii $ php -f mimetest.php char2.csv: text/plain char.cvs: text/x-c $ diff -u char2.csv char.csv --- char2.csv 2012-10-10 15:07:05.0 +0200 +++ char.csv2013-02-25 15:47:38.0 +0100 @@ -1,3 +1,4 @@ stepan.stepa...@somewhere.com stepan.stepa...@somewhereelse.com +charlo...@server.com herr.totalschei...@mime.typ -- $ php -v PHP 5.3.19 (cli) (built: Nov 25 2012 13:17:45) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.1.3, Copyright (c) 2002-2012, by Derick Rethans $ cat mimetest.php file('char2.csv'); echo "\nchar.cvs: ".$finfo->file('char.csv'); ?> [2013-02-18 00:34:31] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". 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=53035 -- Edit this bug report at https://bugs.php.net/bug.php?id=53035&edit=1
Bug #64302 [Opn]: Invalid read in ext/phar/tests/bug52013.phpt
Edit report at https://bugs.php.net/bug.php?id=64302&edit=1 ID: 64302 Updated by: larue...@php.net Reported by:a...@php.net Summary:Invalid read in ext/phar/tests/bug52013.phpt Status: Open Type: Bug Package:PHAR related Operating System: all PHP Version:5.5Git-2013-02-26 (Git) Block user comment: N Private report: N New Comment: same in 5.3 Previous Comments: [2013-02-26 10:24:21] a...@php.net Description: Running the mentioned test with valgrind is to see Expected result: no valgrind warnings Actual result: -- ==22761== Syscall param write(buf) points to uninitialised byte(s) ==22761==at 0x5924EB3: __write_nocancel (syscall-template.S:82) ==22761==by 0x85852E8: _php_stream_filter_flush (filter.c:504) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761==by 0x85615FB: php_execute_script (main.c:2479) ==22761==by 0x875C33C: do_cli (php_cli.c:988) ==22761==by 0x875D785: main (php_cli.c:1364) ==22761== Address 0x6187d1b is 11 bytes inside a block of size 15 alloc'd ==22761==at 0x4024F20: malloc (vg_replace_malloc.c:236) ==22761==by 0x85C3E62: _emalloc (zend_alloc.c:2427) ==22761==by 0x85C4356: _estrndup (zend_alloc.c:2641) ==22761==by 0x81C613C: php_zlib_deflate_filter (zlib_filter.c:250) ==22761==by 0x8585094: _php_stream_filter_flush (filter.c:452) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761== -- Edit this bug report at https://bugs.php.net/bug.php?id=64302&edit=1
Bug #64070 [Com]: Inheritance with Traits failed with error
Edit report at https://bugs.php.net/bug.php?id=64070&edit=1 ID: 64070 Comment by: alexander at mailinator dot net Reported by:denny dot reeh at gmail dot com Summary:Inheritance with Traits failed with error Status: Closed Type: Bug Package:Scripting Engine problem PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: Patch do not included in php 5.4.12. But in php 5.4.13 branch bug fixed: PHP 5.4.13-dev (cgi-fcgi) (built: Feb 24 2013 07:42:48) Previous Comments: [2013-02-22 08:28:51] dmi...@php.net The bug is definitely fixed, However I'm not sure if it's included into 5.4.12 release or not. $ sapi/cli/php bug64070.php >From Second Trait >From First Trait $ sapi/cli/php -v PHP 5.4.13-dev (cli) (built: Feb 21 2013 16:29:23) [2013-02-21 22:16:00] alexander at mailinator dot net Problem has not solved yet. Test snapshot http://windows.php.net/downloads/snaps/php-5.4/r86c1a26/ and bug still present in it. [2013-02-18 12:37:45] dmi...@php.net The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2013-02-18 12:36:39] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=42437dd870de28eee6c9127f4c7e7c78ba8e0152 Log: Fixed bug #64070 (Inheritance with Traits failed with error) [2013-02-18 10:41:18] inefedor at gmail dot com Hi, I checked this problem with the master branch and yes, I was wrong, here's PR I attached to this bug, it solves the problem, but it won't work with xdebug extension. I'm not familiar with code of xdebug, I will contact with Derick about it. 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=64070 -- Edit this bug report at https://bugs.php.net/bug.php?id=64070&edit=1
[PHP-BUG] Bug #64302 [NEW]: Memory leak in ext/phar/tests/bug52013.phpt
From: ab Operating system: all PHP version: 5.5Git-2013-02-26 (Git) Package: PHAR related Bug Type: Bug Bug description:Memory leak in ext/phar/tests/bug52013.phpt Description: Running the mentioned test with valgrind is to see Expected result: no valgrind warnings Actual result: -- ==22761== Syscall param write(buf) points to uninitialised byte(s) ==22761==at 0x5924EB3: __write_nocancel (syscall-template.S:82) ==22761==by 0x85852E8: _php_stream_filter_flush (filter.c:504) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761==by 0x85615FB: php_execute_script (main.c:2479) ==22761==by 0x875C33C: do_cli (php_cli.c:988) ==22761==by 0x875D785: main (php_cli.c:1364) ==22761== Address 0x6187d1b is 11 bytes inside a block of size 15 alloc'd ==22761==at 0x4024F20: malloc (vg_replace_malloc.c:236) ==22761==by 0x85C3E62: _emalloc (zend_alloc.c:2427) ==22761==by 0x85C4356: _estrndup (zend_alloc.c:2641) ==22761==by 0x81C613C: php_zlib_deflate_filter (zlib_filter.c:250) ==22761==by 0x8585094: _php_stream_filter_flush (filter.c:452) ==22761==by 0x831BE2F: phar_flush (phar.c:2903) ==22761==by 0x832B1DE: zim_Phar_compressFiles (phar_object.c:3436) ==22761==by 0x863FFA4: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:542) ==22761==by 0x8641374: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:674) ==22761==by 0x863E004: execute_ex (zend_vm_execute.h:356) ==22761==by 0x863E9BA: zend_execute (zend_vm_execute.h:381) ==22761==by 0x85FF017: zend_execute_scripts (zend.c:1316) ==22761== -- Edit bug report at https://bugs.php.net/bug.php?id=64302&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64302&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64302&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64302&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64302&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64302&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64302&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64302&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64302&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64302&r=support Expected behavior: https://bugs.php.net/fix.php?id=64302&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64302&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64302&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64302&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64302&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64302&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64302&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64302&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64302&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64302&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64302&r=mysqlcfg
Req #62372 [Com]: crypt() and broken backwards compability in SHA rounds
Edit report at https://bugs.php.net/bug.php?id=62372&edit=1 ID: 62372 Comment by: m dot staab at complex-it dot de Reported by:jani dot ollikainen at mmd dot net Summary:crypt() and broken backwards compability in SHA rounds Status: Open Type: Feature/Change Request Package:*Encryption and hash functions PHP Version:5.4.4 Block user comment: N Private report: N New Comment: I have the very same issues. Updating from PHP5.2.4 to PHP5.4.11 and now my passwords which were hased using PHP5.2.4 do not match any longer on PHP5.4.11. I found no way how to re-produce passwords on PHP5.4.11 like they were generated on PHP5.2.4 and therefore I have no way to upgrade users which already have a password to a newly generated with PHP5.4.11.. The only way I can think of is a password-reset for all of our users?! Previous Comments: [2012-06-20 20:33:17] jani dot ollikainen at mmd dot net Oh now I get what I did wrong with PHP 5.1.6. It doesn't understand rounds at all, it's just looks like it does, but it uses it as salt and new PHP doesn't allow = in salt, so it doesn't work as they see different salt in it. So the compatibility issue is with salt string, not in rounds at all. This can be work around in PHP 5.1.6 not to use salt's which newer versions don't understand, but if you already use them, then you're in big trouble. Another one is that if I have password like: http://3v4l.org/amNND The hash is generated with patched PHP 5.4.4 with ROUNDS_MIN 1, but it could be from some other system. PHP cannot verify it, as the rounds limit 1000 is enforced. To me enforcing it seems to limit compability. [2012-06-20 19:32:11] arjen at react dot com Looks like PHP <= 5.1.7 has a limit on the saltstring of 9 chars. If no $rounds is specified AND a salstring of 9 chars, all versions return the same hash: http://3v4l.org/nDiFd (2nd line, 1st line is with long hash). [2012-06-20 11:44:29] jani dot ollikainen at mmd dot net Tested with patched 5.4.4 where: #define ROUNDS_MIN 1 HASH: $6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40 - CRYPT: $6$rounds=10$qNElXs2yMnL2.GNS$YwaYQmhwsN2RzBImxlEjIL.0/YLlfYCDmyfozkCQWNKdKgZQtTpK3Y/TAw31deCnJrDzgrqpI6ckvJCBsoeNB/ NO MATCH So problem isn't only in ROUNDS_MIN. Also I know that my hash hasn't $ after salt, but that's how PHP 5.1.6 creates it. Tested also with adding $ and result is similar: HASH: $6$rounds=10$qNElXs2yMnL2.GNS$3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40 - CRYPT: $6$rounds=10$qNElXs2yMnL2.GNS$YwaYQmhwsN2RzBImxlEjIL.0/YLlfYCDmyfozkCQWNKdKgZQtTpK3Y/TAw31deCnJrDzgrqpI6ckvJCBsoeNB/ NO MATCH So something else is also different... [2012-06-20 10:58:38] jani dot ollikainen at mmd dot net Description: http://fi2.php.net/manual/en/function.crypt.php "CRYPT_SHA512 - SHA-512 hash with a sixteen character salt prefixed with $6$. If the salt string starts with 'rounds=$', the numeric value of N is used to indicate how many times the hashing loop should be executed, much like the cost parameter on Blowfish. The default number of rounds is 5000, there is a minimum of 1000 and a maximum of 999,999,999. Any selection of N outside this range will be truncated to the nearest limit." Why is that N put to minium of 1000? Now if I've made hash with old PHP (or with anything else) which has "$6$rounds=10$" I cannot check that, because if there's rounds mentioned PHP will do minimum of 1000 rounds and I get totally different hash to compare. Sounds very nice! I can understant that rounds limit if I don't give salt to crypt(), but if I give a salt which has "$6$rounds=10$" it really should do just those 10 rounds! Fails with: PHP 5.4.4 (cli) (built: Jun 20 2012 13:48:48) PHP 5.3.14 (cli) (built: Jun 20 2012 13:39:44) PHP 5.3.3 (cli) (built: May 7 2012 19:58:17) Works with: PHP 5.1.6 (cli) (built: May 7 2012 15:03:06) Test script: --- Expected result: HASH: $6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40 - CRYPT: $6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40 MATCH OK Actual result: -- HASH: $6$rounds=10$qNElXs2yMnL2.GNS3kiM7DqmGbFLdQfIwu2691aJgT3xgJazPLtw7RPKz3Dp8RIc4b5fmJ7qvlq/mPN8a.rE40 - CRYPT: $6$rounds=1000$qNElXs2yMnL2.GNS$/q7trYkbKkoJernsumbObt2IysdXGRx/ytFaG0HBC97rHHhYRQvUcyEuRHP6h5yj8V.fH7XKEw5hjofVmYONw1 NO MATCH --