Bug #76873 [NEW]: var_export does not use PHP_EOL, always prints \n (a LF)

From: Date: Wed, 12 Sep 2018 14:19:32 +0000
Subject: Bug #76873 [NEW]: var_export does not use PHP_EOL, always prints \n (a LF)
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-217016@lists.php.net to get a copy of this message
From: martijn at gripp dot com Operating system: Windows PHP version: 7.0.31 Package: Output Control Bug Type: Bug Bug description:var_export does not use PHP_EOL, always prints \n (a LF) Description: ------------ The var_export function should respect your operating system's line endings. In windows, line endings are CLRF, but var_export always outputs RF only, (a '\n'). The PHP_EOL global contains '\n' or '\r\n', on Unix and windows respectively, and the var_export function should use the PHP_EOL instead of the hardcoded '\n'. Relevant files: EOL Definition --- https://github.com/php/php-src/blob/77118fc925b3e84be02a80d8da6bbbb47f8c37e1/main/php.h#L69 Var export definition --- https://github.com/php/php-src/blob/8d3f8ca12a0b00f2a74a27424790222536235502/ext/standard/var.c#L437 See for example this line in the var_export definition: https://github.com/php/php-src/blob/8d3f8ca12a0b00f2a74a27424790222536235502/ext/standard/var.c#L495 The '\n' is hardcoded. This is not a problem on Linux because on Linux '\n' already is the correct line-feed return. Test script: --------------- $example = var_export([], true); // run this on Windows $clrfMatch = preg_match("/(\r\n)/", $example); // should be true $lfMatch = preg_match("/(\n)/", $example); // should be false echo $clrfMatch ? 'true' : 'false'; echo " // should be true" . \PHP_EOL; echo $lfMatch ? 'true': 'false'; echo " // should be false" . \PHP_EOL; -- Edit bug report at https://bugs.php.net/bug.php?id=76873&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=76873&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=76873&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=76873&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=76873&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=76873&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=76873&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=76873&r=needscript Try newer version: https://bugs.php.net/fix.php?id=76873&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=76873&r=support Expected behavior: https://bugs.php.net/fix.php?id=76873&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=76873&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=76873&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=76873&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=76873&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=76873&r=dst IIS Stability: https://bugs.php.net/fix.php?id=76873&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=76873&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=76873&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=76873&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=76873&r=mysqlcfg

« previous php.bugs (#217016) next »