Req #62450 [Com]: Remove gzgetss and see if anyone notices
Edit report at https://bugs.php.net/bug.php?id=62450&edit=1 ID: 62450 Comment by: tero dot tasanen at gmail dot com Reported by:tur...@php.net Summary:Remove gzgetss and see if anyone notices Status: Not a bug Type: Feature/Change Request Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I must say +1 for this.. even this not a bug, this function is just totally pointless. @johannes the koders.com search shows that this function has been used in one actual code file and koders.com covers just about every open source project in the word. (and not to mention that in the line the behavior of this function might actually result in unwanted results since it strips the html tags :D) So I think that it fair to say that this function is not needed by anyone, it's pointless and can safely be removed in future php versions. Previous Comments: [2012-07-06 10:19:04] johan...@php.net A typo in a manual page is no reason for a function be removed. and a quick check shows people are using it: http://koders.com/default.aspx?s=gzgetss&submit=Search&la=PHP&li=* First hit: http://koders.com/php/fid5AEBF8DE39EB1BCA59AC00E6C0960369CC4FDD85.aspx?s=gzgetss#L72 [2012-06-29 14:36:28] tur...@php.net Description: This function (http://php.net/manual/en/function.gzgetss.php) has literally never been used by anyone, ever. Besides the fact that it's worthless, no-one has noticed the error ("striped") on the doc page. We should completely remove the function and see if anyone notices. -- Edit this bug report at https://bugs.php.net/bug.php?id=62450&edit=1
Bug #62437 [Com]: Strange behavior with global variables (objects) in ob_start() output callback
Edit report at https://bugs.php.net/bug.php?id=62437&edit=1 ID: 62437 Comment by: tero dot tasanen at gmail dot com Reported by:tero dot tasanen at gmail dot com Summary:Strange behavior with global variables (objects) in ob_start() output callback Status: Open Type: Bug Package:Output Control Operating System: Linux 64bit PHP Version:5.3.14 Block user comment: N Private report: N New Comment: Yes, I agree that there might be two bugs here. Here's another test script that shows that this only affects objects and not other data types. http://3v4l.org/Ip5Sn bar, $int, sprintf("%.2f", $float), $array[0]); return implode(" ", $ret_val); } ob_start('output'); $object = new stdClass(); $object->bar = "bar"; $string = "foo"; $int = 1; $float = 2.0; $array = array('array'); // $test = $object; ?> Previous Comments: [2012-06-30 13:25:09] Sjon at hortensius dot net Contrary to what tony2001 says in #40604, this was actually working fine until it was broken in 5.2 http://3v4l.org/SUUkK The reason that http://3v4l.org/pZ2PP works might be explained to the second reference to the same object which could prevent destruction, but that would then actually be a bug too (since it indicates a memory-leak). ------------------------ [2012-06-28 11:56:12] tero dot tasanen at gmail dot com Description: Global variables in output buffering seem to work in very strange way. don't know actually if this has anything to do with output buffering callback but see the test case attached to reproduce this. And the strangest thing is that if you uncomment the last line the script works as expected! After some searching I found two similar bug reports (#40604, #44840) and the comments indicate that this is expected behavior?! Not just that it seem really strange that all objects get destroyed before the output callback is called, but why does the use of the $test variable in the end of the script change this behavior? This really does not make any sense! Test script: --- bar; } ob_start('output'); $object = new stdClass(); $object->bar = "bar"; echo "foo "; // $test = $object; Expected result: foo bar Actual result: -- PHP Notice: Trying to get property of non-object in /home/ttasanen/test.php on line 5 PHP Stack trace: PHP 1. output() /home/ttasanen/test.php:0 foo -- Edit this bug report at https://bugs.php.net/bug.php?id=62437&edit=1
[PHP-BUG] Bug #62437 [NEW]: Strange behavior with global variables (objects) in ob_start() output callback
From: tero dot tasanen at gmail dot com Operating system: Linux 64bit PHP version: 5.3.14 Package: Output Control Bug Type: Bug Bug description:Strange behavior with global variables (objects) in ob_start() output callback Description: Global variables in output buffering seem to work in very strange way. don't know actually if this has anything to do with output buffering callback but see the test case attached to reproduce this. And the strangest thing is that if you uncomment the last line the script works as expected! After some searching I found two similar bug reports (#40604, #44840) and the comments indicate that this is expected behavior?! Not just that it seem really strange that all objects get destroyed before the output callback is called, but why does the use of the $test variable in the end of the script change this behavior? This really does not make any sense! Test script: --- bar; } ob_start('output'); $object = new stdClass(); $object->bar = "bar"; echo "foo "; // $test = $object; Expected result: foo bar Actual result: -- PHP Notice: Trying to get property of non-object in /home/ttasanen/test.php on line 5 PHP Stack trace: PHP 1. output() /home/ttasanen/test.php:0 foo -- Edit bug report at https://bugs.php.net/bug.php?id=62437&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62437&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62437&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62437&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62437&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62437&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62437&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62437&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62437&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62437&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62437&r=support Expected behavior: https://bugs.php.net/fix.php?id=62437&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62437&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62437&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62437&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62437&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62437&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62437&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62437&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62437&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62437&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62437&r=mysqlcfg
Bug #48507 [Com]: fgetcsv() ignoring special characters
Edit report at https://bugs.php.net/bug.php?id=48507&edit=1 ID: 48507 Comment by: tero dot tasanen at gmail dot com Reported by:krynble at yahoo dot com dot br Summary:fgetcsv() ignoring special characters Status: Bogus Type: Bug Package:Filesystem function related Operating System: Unix PHP Version:5.* Block user comment: N Private report: N New Comment: I can also confirm that this is an actual bug. File encoding UTF-8, locale settings are set correctly and characters like äöå are dropped from the beginning of the csv column. Tested with php versions 5.2.6, 5.2.10, 5.3.6 Previous Comments: [2011-10-28 08:33:25] peter dot e dot lind at gmail dot com This is definitely still a bug - my locale is set to da_DK.utf8, the file I'm trying to read is in UTF8 (confirmed with a hex-editor but in fact does not matter - the behaviour is the same, UTF8 or ISO-8859-1) yet special characters are still thrown away when they are first in a field [2011-10-18 13:59:30] me at monicag dot it Quoting my fellows above: how comes this is not a bug? [2011-10-10 10:03:58] ghosh at q-one dot com Sorry. I don't understand why this isn't a bug either. Could someone please elaborate? I tried setting all different kinds of locale to no avail. The first letter of a string starting with a UTF-8 character is always missing. IMHO, fgetcsv should work as a simple string operation (or - whatever weird things it does right now - at least have a parameter to do so - count this as a feature request if you wish). I think, the current behavior is totally confusing. For instance, I don't understand why only the first character is missing but the problem doesnt appear if a character is in the middle of a string. [2011-07-17 16:19:28] max dot wildgrube at web dot de The problem does also appears if the special char is preceded by a blank. This blank also disappears. I use this ugly workaround: 1. first reading the complete csv file into a variable: $import 2. $import = preg_replace ("{(^|\t)([â¬-ÿ ])}m", "$1~~$2", $import); 3. after fgetcsv; for each $field of the row array: $field = str_replace ('~~', '', $field); This means: before using fgetcsv inserting a magic sequence (e.g. ~~) on the beginning of a field which begins with a blank or a special char; after parsing with fgetcsv removing it from each field. Max. [2011-07-08 08:39:50] php-bug-48507 at bsrealm dot net This IS a bug. Whatever locale is, I expect this function to read everything between delimiter characters without stripping the contents. Besides, docs say that files in one-byte encoding would read wrong, and there is a different case. This bug causes serious portability issue. In my case, this function was used to read custom database that was storing descriptions entered by users. Some descriptions were in utf-8 enconding. Function just had to read whatever was between delimiter characters and it worked like that on Windows hosting and stopped working after moving to Unix hosting. Note, file itself is not utf-8 encoded and it should not be. It is not related to locale. It must read data, even if it's binary, between delimiters. 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=48507 -- Edit this bug report at https://bugs.php.net/bug.php?id=48507&edit=1