Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

I can not reproduce this.

I was able to. You have to be very careful not to have any whitespace after the <?
php — if your editor adds a newline (like vi), then that will cause it to be OK.

What I'm not so sure about is whether this is really a bug: the whitespace at the 
end of the opening tag is really part of the opening tag, so it may just need a 
documentation update to be clearer.

Parser people? What's our expectation here?

@aharvey ah, thanks,  in that case, I would say, this is a rare usage, and a doc 
will be okey.

<?php is an XML PI tag. The full grammar for the tag as defined by the spec is:

PI	   ::=   	'<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>'

The PITarget in this case is 'php'. The 'S' in the grammar there means 
whitespace. The first whitespace character signifies the end of the PITarget. If 
you have no whitespace you do not have a valid PI tag.

Reopening as a doc bug and assigning to myself -- we could be a little clearer 
about this on the escaping from HTML manual page.

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.

I don't think the doc changes reflect reality.

The behaviour is different with/without short_open_tag enabled.

I tried the following with 5.1.0, 5.2.0, 5.3.0 and 5.4.0.

With short_open_tag On:

A file containing only "<?php" issues a Parse Error (unexpected $end/end of 
file) in all four versions.  A file containing only "<?php " executes without 
error in all four versions.

With short_open_tag Off:

A file containing only "<?php" prints that out, there is no Parse Error. A file 
containing only "<?php " executes, as with short_open_tag on, without error in 
all four versions.



The suggestion here would be to get rid of that paragraph in the docs and 
mention that some form of whitespace is always needed after the long opening tag 
to move into "PHP mode".

Closing this off. I can live with the current doc.