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
