This can also be used to define classes after use in a file.
<?php
eval(file_get_contents(__FILE__, false, null, __COMPILER_HALT_OFFSET__));
var_dump(class_exists('Foo'));
__halt_compiler();
class Foo {}
(PHP 5 >= 5.1.0, PHP 7)
__halt_compiler — 中断编译器的执行
中断编译器的执行。常用于在PHP脚本内嵌入数据，类似于安装文件。
可以通过常量 __COMPILER_HALT_OFFSET__ 获取数据开始字节所在的位置，且该常量仅被定义于使用了__halt_compiler的文件。
没有返回值。
Example #1 __halt_compiler() 例子
<?php
// open this file
$fp = fopen(__FILE__, 'r');
// seek file pointer to data
fseek($fp, __COMPILER_HALT_OFFSET__);
// and output it
var_dump(stream_get_contents($fp));
// the end of the script execution
__halt_compiler(); the installation data (eg. tar, gz, PHP, etc.)
Note:
__halt_compiler() 仅能够在最外层使用。
This can also be used to define classes after use in a file.
<?php
eval(file_get_contents(__FILE__, false, null, __COMPILER_HALT_OFFSET__));
var_dump(class_exists('Foo'));
__halt_compiler();
class Foo {}
If "__halt_compiler();" appears in a file which is "include"d or "require"d, then the called-in file will be treated as if it physically cuts off at the "__halt_compiler();". In other words, "__halt_compiler();" only affects the physical file it's in, an outer file that pulls it in will continue to execute.
if you find the value of __COMPILER_HALT_OFFSET__ is highly strange. Maybe...
there are some complier optimization tools, like eAccelator(very old). When the program is pre-complied and cached, the __COMPILER_HALT_OFFSET__ will be 0 = =
Joey, you're wrong saying that __halt_compiler have strange behavior. This structure works exactly the same as any other build in structure like empty or isset (even similarly to functions; at least in tokenizer level).
About T_OPEN_TAG - after one open tag is present you didn't expect other one in current php code section, so tokenizer try to handle this "thing" in other way and it's perfectly normal...
I don't exactly know what PHP is doing internally but I don't understand the sanity behind how in token_get_all __halt_compiler is handled.
This is actually valid there:
__halt_compiler/**/ /**/ /**/ /**/ /** */();raw
Normally it pops off just any three tokens so you can have even __halt_compiler***, __halt_compiler))), etc in token _get all.
The weird thing is that is also skips T_OPEN_TAG but in the context __halt_compiler runs in this tag should not be posible. Instead it will pick up < and ? as operators and php as a T_STRING.
It ignores the token at any point so this is also valid:
__halt_compiler()/**/ /**/ /**/ /**/ /** */;raw
When I test this with a php file rather than the tokeniser it works the same.
I can only conclude that PHP/__halt_compiler is pretty weird.
I think this is from attempting to weakly imitate the same syntax handling as in functions (I guess you can put comments/whitespace anywhere). I find it annoying and counter productive though.
Even this is valid:
__halt_compiler// comment\n();raw
A general problem that compound matters is that tokenise wont check whether or not syntax is valid (tokens against each other). When running as PHP you must have ();.
This function can be used in eval() -- it will halt the eval, but not the script eval"() was called in.
__halt_compiler is also useful for debugging. If you need to temporarily make a change that will introduce an error later on, use __halt_compiler to prevent syntax errors. For example:
<?php
if ( $something ):
print 'something';
endif; // endif placed here for debugging purposes
__halt_compiler();
endif; // original location of endif -- would produce syntax error if __halt_compiler was not there
?>