Could you plz try the same on Linux?
I can't replicate it there.

Hi - sorry - I should have mentioned that the behaviour is not reproducible on Linux. It's Windows specific. Would you like the copies of the data.tmp files that are created in each case? - if so I'll attach them to this.

No, thanks. This should be enough for somebody who knows how to debug it on Windows. 
Unfortunately, I don't.

I'd assume this is some ICU feature when converting a text with newlines from UTF-8 to UTF-16 and then back to UTF-8.

Does something like
<?php
$a = "foo\nbar";
var_dump((binary)$a);
?>
also show the \r?

Hi Johannes

No, it doesn't:

E:\zoe\TESTS\slashr>e:\zoe\buildsystem\php6exe\php.exe -d unicode.semantics=0 johannes.php
string(7) "foo
bar"

E:\zoe\TESTS\slashr>e:\zoe\buildsystem\php6exe\php.exe -d unicode.semantics=1 johannes.php
string(7) "foo
bar"

when files are not opened with the binary flag, windows automatically converts \n to \r\n. I don't have time until mid-July to investigate this problem though.

"when files are not opened with the binary flag, windows automatically
converts \n to \r\n. I don't have time until mid-July to investigate
this problem though."

As far as I remember, it is the documented behavior (windows file functions).

It is especially important to take care of text contents in the unicode mode, it is not a good idea to blindly save everything as binary. That's why php6 has two new flags which can be used in file_put_contents: 
- FILE_TEXT, opens with "wt" (or "at" if FILE_APPEND is used)
- FILE_BINARY, opens with "wb" (or "ab"

the default mode is "w", which is a text mode on windows.

I do not have a windows at hand to test but I'm pretty sure that FILE_BINARY solves your issue. It may use it automatically when a binary string is given, but I would find that trickier (magic++).

Yes - you are right. The FILE_BINARY flag does fix the problem. I'm closing this.

Not a bug > bogus (I don't like this word but well :)

Fair enough - I was wondering if it should also be either RTFM or WTFM?
Just had a quick look at what I hope are the PHP6 docs and I can't see the new put_file_contents() flags documented yet. *IF* there is some work needed on the docs is the right process to open another defect?

"*IF* there is some work needed on the docs is the right process to open another defect?"

Good point, there is a lot of work to be done regarding php6 behaviors of each function. I'm not sure what the phpdoc team decided but I will let them comment here, if required.

changed to open + documentation problem.

"I'm pretty sure that FILE_BINARY solves your issue. It may use it automatically when a binary string is given, but I would find that trickier (magic++)"

I don't see that as magical.. If a binary string is given, you want it writen as-is, IMHO. I'm classifying back to a PHP bug, because I feel this needs more discussion.

"I don't see that as magical.. If a binary string is given, you want it
writen as-is, IMHO. I'm classifying back to a PHP bug, because I feel
this needs more discussion."

Yes, but it is still magic as it introduces possible confusions and wtf factors. Having to specify the mode just like you do with fopen is clear and not confusing. It is only in Unicode mode so no BC involved either.

"Having to specify the mode just like you do with fopen is clear
and not confusing."

Well - this made me think of trying something else. In the following test case:

<?php
$file_path = dirname(__FILE__);
$buffer = "text\nline of text\n";
$nbytes_fpc = file_put_contents( $file_path."/data_fpc.tmp", (binary)$buffer);


$fh = fopen( $file_path."/data_owc.tmp", "w");
$nbytes_owc = fwrite ($fh, (binary)$buffer);
fclose ($fh);

echo "Bytes fpc = $nbytes_fpc Bytes owc = $nbytes_owc \n";
?>

file_put_contents creates a file with \r, whereas using fopen() doesn't. I tried using "wb" in fopen and got the same result.

The interesting thing is that this behaviour is only seen with unicode.semantics=1, when unicode.semantics=0 the two files in the tescase above are identical.

I'm not sure whether this makes it a doc or a code defect :-) Just more information....

"file_put_contents creates a file with \r, whereas using fopen() doesn't. I tried using "wb" in fopen and got the same result."

file_put_contents should be used with the new flag. I'm not sure what we should do for fopen, I think we should make it consistent.

About forcing the binary mode if a binary string is given, this patch should do the trick for file_put_contents:

http://blog.thepimp.net/misc/patches/php/bug41609_force_binary.txt

Hi
Sorry for the delay in replying - it took some time to get PHP to build on Windows :-).

I can confirm that this patch makes the behaviour of file_put_contents() consistent with that of fwrite()with unicode.semantics=1 in PHP6. It doesn't seem to have regressed anything else so please would you commit it?

The extra flags would still need to be added to the docs.

"please would you commit it?"

Done

"The extra flags would still need to be added to the docs."

Move back to documentation.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.