Actually it is not only var_export(), var_dump() also uses hardcoded LF.

I can repro this on 7.2.2.

var_export() returns \n (10) before the ) character.

The doc for var_export() doesn't specify a \n or \r\n behavior. The doc does specify var_export() should return executable PHP code. Except for Windows Notepad, text editors, IDEs, etc... shouldn't have a problem with this. They can automatically handle both \r\n and \n in same document. So the code var_export() returns can be edited and executed in text editor, IDE, etc...

On Windows 10, the command prompt does handle \n as if it was \r\n. PHP_EOL on Windows does return \r\n to avoid causing problems for terminal emulation.

In userland, var_export() output is often not (only) dumped to terminal but may be used with string parsing, persistence, etc...  Switching to \r\n, because it would add an additional byte/char could break that. Or at least cause a slight performance problem.

It may technically be a bug. But given userland code and that Windows command prompt and text editors can handle \n instead of \r\n, I think this should be reclassified as a "Won't fix".

-Thoughts?


A more clear repro script:
<?php
	$a = array('a' => 1);
	echo var_export($a, true);
	echo strlen(var_export($a, true));
	
	$b = var_export($a, true);
	echo $b;
	echo strlen($b);
	
	function ord_array($str) {
		$ords = array();
	   
		for($i = 0; $i < strlen($str); $i++){       
			$s2 = substr($str,$i,1);
			$ords[] = ord($s2);
		}       
		return($ords);
	}

	echo PHP_EOL;

	echo var_dump(ord_array($b));
?>

see previous comment