Description:
------------
The documentation for the tmpfile() function is wrong and misleading:

"The file is automatically removed when closed (for example, by calling fclose(), or when there are no remaining references to the file handle returned by tmpfile()), or when the script ends.

For details, consult your system documentation on the tmpfile(3) function, as well as the stdio.h header file."

The fact is php does *not* use tmpfile(3) for its implementation. That C function *guarantees* that there will not be a temporary file left on disk once the program exists, as the file is unlinked even before tmpfile(3) even returns.

However, as php relies on its own internal implementation of temporary files instead of using tmpfile(3), not only is the file not unlinked before returning the handle, but zombie files on disk are possible. This is shown in the attached test script.

Please update the documentation to not only remove the misleading information about tmpfile(3), but to explicitly state and warn that the function does *not* use tmpfile(3). Php devs are used to a C-named function being C-equivalent, and it causes problems when this is not the case.

Test script:
---------------
<?php

// 1. run this script from command-line, do steps 2 and 3 while sleeping.
// 2. check temp directory. file exists, would not be the case with tmpfile(3).
// 3. ctrl+c quit the running script. temp file is zombied, not unlinked.

$fh = tmpfile();
sleep(500);

Expected result:
----------------
Technically, I would expect php's tmpfile() to use tmpfile(3). However, I have seen existing code using tmpfile() and then stream_get_meta_data() to extract the 'uri' argument to manipulate the file on disk (ex: using it with ZipArchive::open()). Since a proper tmpfile(3) implementation would result in no accessible file on disk, this type of code would break.

So instead update the documentation to reflect that tmpfile() does not use tmpfile(3) and that zombie temporary files are possible if php exits unexpectedly.