#22407 [NEW]: Unix formatted text file parsed with DOS characters interpreted

From: dci at webquill dot com Operating system: FBSD 4.6-RELEASE PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: Unix formatted text file parsed with DOS characters interpreted I did note something similar in bug #10858, but that was in regards to an older version of PHP and it seemed like the feedback was never provided to solve the issue. We've got code that is in a Unix formatted text file, and on one of the lines, we somehow ended up with a literal ^M character (a DOS newline feed). Although this had nothing to do with PHP, it produced very strange results -- the line in question began with a single line comment ( // ), and the ^M was in the middle followed by an old if statement. I suspect this came about because our code was originally a quick conversion from an ASP site utilizing asp2php. The odd part, however, is that even tho editors (vim, emacs) would show the line as being a comment, and on one line, PHP would interpret the ^M as a newline, and then parsed the code after it. Because this was a comparison between 0 and a variable that did not exist (thus returning 0), the new comparison for the if, which was on the next line, was never processed. Here is some example code (I am afraid I cannot provide full-code due to restrictions placed on me by my employer): error_log( "SQL: $ssql" ); $res = pg_query( $dbconn, $ssql ); error_log( "pg_last_error: " . pg_last_error($dbconn) ); error_log( "Number of results: " . pg_num_rows($res) ); //only send if there's an Email to send to^M if (!($get_email==0)) if( pg_num_rows($res) > 0 ){ error_log( "here" ); The line beginning with // and ending with ($get_email==0)) is all one line. The first error_log showed the correct SQL, pg_last_error reported to errors, and pg_num_rows correctly logged 1 result row. We discovered the problem when the error_log("here") statement was never being executed. Upon removing the ^M character, everything performed as expected, and the "here" statement was logged in the error_log. The following code was then executed. Now I realize that this could potentially be by design, because of the cross-platform nature of web development (due to all those silly Windows users out there and their bad character set ;), but I would suspect that if the entire file is being parsed as a particular format text file that characters not indicating a linefeed in that format should not be interpreted as such. It is my guess (without taking time to examine the PHP source code) that PHP is not examining the file type and is merely interpreting all linefeed characters as new lines and not determining file format. A thought after finally tracking down a very odd problem.. Other than that, thank you for a wonderful product! -chris -- Edit bug report at http://bugs.php.net/?id=22407&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22407&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22407&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22407&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22407&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22407&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=22407&r=support Expected behavior: http://bugs.php.net/fix.php?id=22407&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=22407&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=22407&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22407&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22407&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22407&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22407&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=22407&r=gnused