reproducible in dev branches (5.2 and head), on other OS/platform than OSX as well.

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

You may be confused with your "virtual" lines (as I was as well :). worwrap does wrap at the pos. 9 and this is what it does. Word are not cuted.

No, I think you're the only one who is confused. ;-) I'm 
pretty sure this is a bug. The problem is that PHP only cuts 
some of the lines (the third in my example) at position 9, and 
incorrectly cuts some lines (the fifth in my example) at 
position 8.

"wordwrap() - Returns a string with str wrapped ****AT**** the column number specified by the optional width parameter."

"Some text" <- the last "t" is symbol #9, so whole "text" word is wrapped (since you didn't pass third argument).

You seem to be just as confused as the other guy. ;-) Sure, 
I guess the slight vagueness of the documentation could 
allow you to argue that wordwrap() wraps the third line 
incorrectly and the fifth one correctly instead of the other 
way around. But that doesn't negate the fact that this is a 
bug, it would just make it a much bigger bug, affecting the 
majority of lines wrapped by wordwrap() instead of the 
minority. Also note that your claim is refuted by the 
examples in the documentation, specifically the line "jumped 
over the lazy" which is 20 characters long.

I urge you to look at the expected result and the actual 
result and consider why wordwrap() thinks "Some text" fits 
on one line while "Some text" doesn't, given that they both 
start at the beginning of a line.

$s = ' s '.
     ' t '; 
is equal to
' s  t '
If you really want to get several text lines - you need to use "" and \n.

Wow, I don't know how it's possible to misunderstand such a 
simple bug report so extensively.

Jesus H. Christ, will you please try to actually read the 
bug report before closing it as bogus.

Again:

I URGE you to look at the expected result and the actual 
result and consider why wordwrap() thinks "Some text" fits 
on one line while "Some text" doesn't, given that they both 
start at the beginning of a line.

If you find the reproduction code formatting confusing, try 
reformatting it as such:

<?php
$input = 'Some tex Some tex Some text Some tex Some text 
Some tex';
echo '<pre>'.wordwrap( $input, 9 )."</pre>\n";
?>

(Unfortunately the bug tracking system reformatted the code in 
my last comment, adding a line break in the statement that 
sets the $input variable, which was not intended to be there. 
There is supposed to be a space (and only a space) between 
each word in the string. So you'll need to change that if 
copying-and-pasting. Or just use my first reproduction 
example.)

Oh, god..

Here is what wordwrap() does:
"Some tex|Some tex|Some text| Some tex| Some tex|t Some tex"
Write it down on paper and count symbols yourself.

Is everything clear for you this time? Or do I need to explain how to count from 1 to 9?

<?php
//     'Some tex Some tex Some text Some tex Some text Some 
tex';
$foo = "1234 678 1234 678 1234 6789 2345 789 2345 7890 2345 
678";
print wordwrap($foo, 9) . "\n";
?>

1234 678
1234 678
1234 6789
2345 789
2345
7890
2345 678

The latter "t" in "text" is the TENTH character.
Now PLEASE leave this report as bogus.

Sorry for my tone earlier. It didn't seem like anyone 
understood my bug report.

It is only the tenth character if you count the leading 
space, which doesn't exist, because it has been trimmed. 
Your explanation would make sense if wordwrap() didn't trim 
leading (or trailing) spaces from wrapped lines; resulting 
in something like:

Some tex 
Some tex 
Some text
 Some tex
 Some
text 
Some tex

(note leading and trailing space on lines)

But that's not what wordwrap() returns. The fact that (I'm 
guessing) the trimming internally occurs after the counting 
is merely an implementation detail of wordwrap() that 
shouldn't be exposed outside the function.

I'd suggest fixing wordwrap() to wrap more efficiently. 
Given the trimming of spaces, that can hardly be considered 
to be incorrect.

Either that, or adding the following note to the 
documentation:

Note that if a line happens to be exactly as long as the 
maximum line length, the following line will be considered 
to start with a leading space, even though it does not do 
so, for porposes of calculating the maximum amount of text 
that can fit on that line.

Unbogusing again, as per my previous comment.

(As for needing to explain to me how to count from 1 to 9, 
apparently you do. I was under the assumption that one should 
always start at 1...)

There is nothing to discuss.
bjori and me already explained you every bit of your code.
Please STOP reopening this BOGUS report.
Thank you.

I only reopen the bug because your responses keep failing to 
address my comments. As with the majority of your previous 
comments, your last comment implies to me that you either 
haven't read, have misunderstood or have understood but 
choose not to respond to my latest comment.

You think counting characters that don't exist is logical? 
And you will not consider adding the note to the 
documentation?

I will only reopen this bug if you fail to answer these 
questions.

$foo = 'Some tex Some tex Some text Some tex Some text Some tex';
$foo = '1234 678 1234 678 1234 6789 2345 789 2345 7890 2345 678';
If you fail to understand this, I don't think I can help you, sorry.

Again, please try reading before responding. You've still 
failed to answers to my questions. See specifically my comment 
from 20 Jun 2:39pm UTC. Thank you.

Tony, the OP is right -- you haven't addressed his complaint.  There's a function to do what you're describing, but it's called chunk_split(), not wordwrap().

The originally supplied Expected and Actual Results pinpoint exactly the problem.  Pierre's confirmation of it on multiple platforms indicates it's not a figment of the OP's imagination, but a real genuine bug.

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.