Magic constant FILE and DIR of values is source code path, whether need replace to opcdoe file path at compile time
Hi Chopins Xiao,
Some comments on https://wiki.php.net/rfc/direct-execution-opcode
- This should be marked as "Status: Under Discussion" in the RFC document itself, not draft?
- https://wiki.php.net/rfc/howto states:
- Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the issues and discussions.
Cover both the positive and negative arguments. Put the RFC URL into all your replies.
The RFC guidelines mention this should document the negative arguments,
e.g. as a Discussion section with quotes of the negative arguments (arguments against the RFC)
and positive arguments.
I'd recommend linking to the discussions on the mailing list, as there had been a lot of discussion there,
e.g. as a References section at the end of the document
https://externals.io/message/112482 and https://externals.io/message/111965 and https://externals.io/message/111979
https://wiki.php.net/rfc/direct-execution-opcode#backward_incompatible_changes was also unclear to me
Magic constant
__FILE__
is the absolute path to the compiled source file, not the path to the opcode file that is currently executing
"to the compiled source file" should be clarified to say something like "to the compiled source file for the packager (not the end user)"
(e.g. require_once __DIR__ . '/other.php'
would get converted to the opcode INCLUDE_OR_EVAL (require_once) string("/home/packagerusername/other.php")
even with optimizations disabled, which would be unexpected for the packager and the end user)
I don't think there are any problems with __LINE__
, that's the line number within the file, and is unchanged by the path to the file.
Regards,
- Tyson
Thanks Tyson for pointed out the problem
I will change the RFC status to "Under Discussion".
The answer is unified here:
- Default, different versions of opcode files are prohibited from being executed.
- The FILE , DIR and other PHP's constant is like C Macro. When compiled, they are replaced with actual values. In php, It will be replaced when compiled into opcode. so opcode file will store the absolute path to the currently compiled PHP file(Compile time). All platform-related constant values are replaced with values related to the current compilation environment
Regards
发件人: tyson andre tysonandre775@hotmail.com
发送时间: 2020年12月13日 0:50
收件人: €– ”k”k chopins.xiao@gmail.com; internals@lists.php.net internals@lists.php.net
主题: Re: [rfc:direct-execution-opcode] Whether need FILE the value of the file to replace the compiled opcode file path
Hi Chopins Xiao,
Some comments on https://wiki.php.net/rfc/direct-execution-opcode
- This should be marked as "Status: Under Discussion" in the RFC document itself, not draft?
- https://wiki.php.net/rfc/howto states:
- Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the issues and discussions.
Cover both the positive and negative arguments. Put the RFC URL into all your replies.
The RFC guidelines mention this should document the negative arguments,
e.g. as a Discussion section with quotes of the negative arguments (arguments against the RFC)
and positive arguments.
I'd recommend linking to the discussions on the mailing list, as there had been a lot of discussion there,
e.g. as a References section at the end of the document
https://externals.io/message/112482 and https://externals.io/message/111965 and https://externals.io/message/111979
https://wiki.php.net/rfc/direct-execution-opcode#backward_incompatible_changes was also unclear to me
Magic constant
__FILE__
is the absolute path to the compiled source file, not the path to the opcode file that is currently executing
"to the compiled source file" should be clarified to say something like "to the compiled source file for the packager (not the end user)"
(e.g. require_once __DIR__ . '/other.php'
would get converted to the opcode INCLUDE_OR_EVAL (require_once) string("/home/packagerusername/other.php")
even with optimizations disabled, which would be unexpected for the packager and the end user)
I don't think there are any problems with __LINE__
, that's the line number within the file, and is unchanged by the path to the file.
Regards,
- Tyson