RTFM: http://www.php.net/manual/en/function.tmpfile.php

tmpfile() returns a file handle already..NOT filename.
I doubt this ever worked for you as this was not changed in 4.3.0...(you propably used tempnam() instead before)

Per me previous comment addition, the code was not changed whatsoever.  I'm "re-opening" this bug report in the hopes it will gather a response.

As Jani said, tmpfile returns a resource, no need to try to fopen it. He said also that nothing was changed in 4.3.0 about it, which is right. Your code is bogus and I don't think it ever worked.

See: http://www.php.net/manual/en/function.tmpfile.php

resource tmpfile ( void)

Creates a temporary file with an unique name in write mode, returning a file handle similar to the one returned by fopen(). The file is automatically removed when closed (using fclose()), or when the script ends. 

You should use:
$temp = tmpfile();
fwrite($temp, "writing to tempfile");
fclose($temp); // this removes the file

Not a bug->Bogus again.

I don't consider this bogus and your thoughts are your own.  I wouldn't be the type to just submit a bug report that I didn't think was founded.  The code worked under 4.2.3 and if you care to check I can send the whole package to you to disprove your "thoughts".

Upgrading to php 4.3 has broken the subroutine.  Instead of "thinking" that it doesn't work I would suspect more from php developers for a more quantitative analysis of the situation.

Ergo I prefer to close this bug report myself because I'm apparently not getting any constructive feedback here, instead of having it labeled as "bogus".

Once again, the code, unchanged prior 4.3 worked.  The same exact code that worked no longer does.  Absolutely nothing has been changed.

Anyhow, thanks for replying at least.  It is much better to know where one stands rather than not getting any reply whatsoever.

User error.
Please leave this as bogus.

"Warning: fopen() expects parameter 1 to be string"
Now read the manual for fopen -> parameter 1 needs to be a string.
You are passing a resource.

The fact that this "worked" for you in 4.2.3 indicates a bug in 4.2.3 that has been fixed in 4.3.
Your supposed temporary file name would be a string "Resource id #4", which isn't a very good temporary file name.

You describe the expected behaviour of PHP, your script is broken, therefore this is a user error, and thus a bogus report.

Now, please leave us in peace to fix real bugs.

Quote: "The fact that this "worked" for you in 4.2.3 indicates a bug in 4.2.3 that has been fixed in 4.3."

Now that is an idea that didn't occur to me.  And since php 4.2.3 may have been buggy then obviously the fix is to upgrade to 4.3 and rewrite it the way you folks suggest.

Thanks for that answer, a much more mature one than RTFM.

Hence this isn't bogus but an actual bug that was in 4.2.3.  And the patch is to make sure the code is written correctly.

Thus one last question, looking at the code I initially posted, what would be your suggestion if I may ask specifically tailored to my problem?

For support:
http://www.php.net/support.php

Thanks.

my 2c on this:

yes it worked in 4.2.3 ...

but even in 4.2.3 it didn't do what you wanted,
instead of creating a temp file with a unique
name (or better in addition to it) your fopen
statement opens a file by the name of the 
auto-converted resource number, so if you investigate
this you'll find out that your temporary files
are actualy namend by small numbers, and if
your code always opens the same resources
you'll even get temp files of *equal* names
by different script runs -> not what you want

so 4.3 now warns you about this were 4.3.2 
silently accepted it

"that same exact code block worked 100% under php 4.2.3."
is just not true, as it would create race conditions
if run simultaneous multiple times even in 4.2.3


"Thus one last question, looking at the code I initially posted, what
would be your suggestion if I may ask specifically tailored to my
problem?"

you've been told before in this thread: either use temnam() instead of tmpfile(), or use the file handle resource returned by temfile() right away instead of trying to perform unspecified operations on it ...


"I don't appreciate the RTFM remark, but I am glad you replied back.  I
use the php manual extensively but have not seen that particular link."

so you use functions without reading their specs and then complain about them not working as you'd expect? strange concept ...

Thanks for the reply.  I ran a search on the functions you listed and couldn't find them: 

a) temfile

http://www.php.net/manual-lookup.php?pattern=temfile&lang=en

b) temname

http://www.php.net/manual-lookup.php?pattern=temname&lang=en

Why are they not listed in the manual?

"so you use functions without reading their specs and then complain
about them not working as you'd expect? strange concept ..."

I don't believe in this bug report I ever said the script was written by me.  You see the script that I "have" was released GNU GPL to the public and I was conducting tests on it in two difference versions of PHP.  Because it doesn't function under 4.3 I was trying to be kind in debugging it and releases the "bug fix" to the community-at-large.

This is precisely why I am not 100% familiar with the code because I didn't write it.

This has all been about the gesture of goodwill.