[PHP-DEV] Seg fault with custom extension on dlclose
I'm writing an extension that uses Google's V8 engine. I'm getting a
segfault after my module has been unloaded.
Here is what I get when running PHP:
DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 /phpdev/bin/php -f
/Server/www/localhost/test.php
dyld: loaded: /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so
dyld: loaded: /phpdev/lib/libv8.dylib
string(11) "Hello World"
dyld: unloaded: /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so
dyld: unloaded: /phpdev/lib/libv8.dylib
Segmentation fault (core dumped)
This is the stack trace of the core dump:
#0 0x7fff5fc1face in __dyld_munmap ()
#1 0x7fff5fc10e8c in __dyld__ZN23ImageLoaderMachOClassicD0Ev ()
#2 0x7fff5fc04bad in __dyld__ZN4dyld20garbageCollectImagesEv ()
#3 0x7fff5fc09e9a in __dyld_dlclose ()
#4 0x7fff83133665 in dlclose ()
#5 0x0001005baa8c in module_destructor (module=0x100d52c10) at
zend_API.c:2138
#6 0x0001005c6927 in zend_hash_apply_deleter (ht=0x100a748e0,
p=0x100d52bc0) at zend_hash.c:612
#7 0x0001005c6b38 in zend_hash_graceful_reverse_destroy
(ht=0x100a748e0) at zend_hash.c:647
#8 0x0001005aa6e4 in zend_shutdown (tsrm_ls=0x100d000f0) at zend.c:759
#9 0x0001004e9935 in php_module_shutdown (tsrm_ls=0x100d000f0) at
main.c:2186
#10 0x00010071bb0e in main (argc=3, argv=0x7fff5fbffa30) at
php_cli.c:1377
Here is the test PHP code:
$v8 = new V8();
var_dump($v8->run("'Hello World'"));
The "run" function is almost identical to the second snippet on this page:
https://developers.google.com/v8/get_started , difference being I'm doing
RETURN_STRING(*ascii, 1).
(If providing a core dump helps, I can do that as well)
Anyone know what could be causing this?
Luke
[PHP-DEV] Re: Why is my library linking to the wrong path?
> I'm using the line: > > PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD) > > Where the path is /phpdev/lib. But my extension is actually linking to > /v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even though > /v8/out/x64.release no longer exists. > > What am I doing wrong? > > Luke Was probably super obvious, but install_name_tool is how you fix the issue. First use the "-id" parameter on the .dylib to fix the dylib. Then recompile (or fix with -change flag). Luke
Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening
On Apr 11, 2012, at 12:02 PM, Chris Stockton wrote: > Hello, > > On Wed, Apr 11, 2012 at 11:47 AM, Luke Scott wrote: >> >> The .php extension really isn't used by PHP, but it's used by a web server >> to identify PHP code and send it to the interpreter. Any mention of file >> extensions in the RFC would have to be nothing more than a recommendation. >> I do understand that if a .php file didn't have a starting > unintentionally get printed... But it's nothing we can really gurantee. >> That's why "template mode" has to remain the default. However, I think >> it's prudent to provide an environmental variable to let the web server >> choose what mode to use. That way you can instruct Apache/Nginx to >> interpret .phpc as "pure code mode" and ".php" as the current "template >> mode". >> >> The most exciting thing for me in this RFC is disallowing the use of ?>. A >> starting > first. I wouldn't be opposed to making the starting > mode, but that's not what Tom wants. I just want a mode where you don't >> have ?>...> just leaves me with a WTF moment (After all we have heredoc/nowdoc). >> > > I very much understand how the extension relates to various web > servers. The thing is every single distribution, rpm, deb package etc > that shared servers and private repos have around the world are > configured to use .php. If PHP Version X. releases with a new feature > advocating the use of a new extension a burden is placed on those > various distributions and package maintainers for security reasons to > add this new extension to the web server configurations. Who / how is > that being communicated to them? That is why a RFC including > extensions as a convention seems a little off / unsafe for me. Again > not something I feel strongly about, but something to be considered. True. Which is why I would add >> When I use get_defined_constants(TRUE); I didn't see any PHP_ constants. >> There are many built in constants that don¹t' follow this rule, and follow >> their own conventions. T_* for example is reserved for tokens. If this is >> indeed a requirement, I don't mind as long as these constants aren't >> insanely long. But if it's not a requirement, I'd prefer not to have the >> PHP_*. It's a bit redundant. >> > > Most extensions have their own constant space The T_* space parser > tokens are listed in the documentation and are registered under the > tokenizer space. Some other extensions might may not be highly > consistent with how they prefix their constants, that is up to the > developer of the extension. However include/require are reserved words > and part of the php core, as such it would make sense to me that they > would be registered under the core constant name space which is mostly > understood as PHP_. No reason this couldn't be deviated from, as > UPLOAD_* and ZEND_* have their own spaces, but INCLUDE_* seems pretty > generic to reserve and seems safer under PHP_* to me. This is a small > detail I don't feel strongly about, but it is a detail that should be > considered. Yeah, i'm not sure. Would like for more people to chine in. Its more cosmetic though. I just would prefer it not to be sinething like: PHP_INCLUDE_PURE_PHPCODE. It's a lot to type! Also long keywords make it difficult to stick to 80 characters per line. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening
On 4/11/12 11:27 AM, "Chris Stockton" wrote: >Hello, > >On Wed, Apr 11, 2012 at 11:14 AM, Tom Boutell wrote: >> On Wed, Apr 11, 2012 at 1:48 PM, Chris Stockton >> wrote: >>> I have read the RFC and I although from what I gather it seems that >>> .phpp is a recommendation and not a requirement, but I want to make >>> absolutely sure. >> >> >> That is correct, it is not a requirement. However if you know of any >> reason why .phpp would be a bad choice of file extension for PHP >> source files without in them, now would be a good time to >> share that input. >> > >Something about PHP advocating it makes me feel a little uneasy, I >guess it can at least help frameworks have a unified standard for >their auto loaders etc. My main concern is people expecting .phpp will >"just work" when including via apache on shared hosting servers etc. >End up with a file full of code, passwords, who knows what downloaded >or displayed in a browser. The burden of responsibility here is not >entirely clear for me, but I am just not sure I like proposing a >separate PHP extension, just seems a little wrong. However from what I >see no one else has said anything so perhaps I am wrong. I will say if >I was developing a framework I might try to think of other >alternatives for my auto loading / detecting of pure php files. I.E.a >specific folder like "purephplib" a specific portion of the file name >or something like "Class_Name_Pure" (like this much less then folders, >but I think more then a file extension. Just my two cents. The .php extension really isn't used by PHP, but it's used by a web server to identify PHP code and send it to the interpreter. Any mention of file extensions in the RFC would have to be nothing more than a recommendation. I do understand that if a .php file didn't have a starting . A starting ... >>> My only other issue is that we are not really following the guidelines >>> for reserved constants, since "include" is not part of a "include" >>> extension and a actual language construct it feels like it should live >>> inside the reserved PHP_* constants. There may be projects that make >>> use of "INCLUDE_ONCE" as a constant or maybe not, regardless I think >>> it should follow the documented naming guidelines to be safe. >> >> I wasn't aware of those guidelines. This makes sense to me. >> PHP_INCLUDE_ONCE, then? >> > >I will let others comment here, was just my initial thoughts. When I use get_defined_constants(TRUE); I didn't see any PHP_ constants. There are many built in constants that don¹t' follow this rule, and follow their own conventions. T_* for example is reserved for tokens. If this is indeed a requirement, I don't mind as long as these constants aren't insanely long. But if it's not a requirement, I'd prefer not to have the PHP_*. It's a bit redundant. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
I do agree with a lot of what was being said. But what can you do? These are mostly quirks of the language. You learn to live with them. I don't make excuses for it. It is what it is. The only thing that infuriates me is the ternary operator being left associative. I want that fixed - screw bc on that one! I have been programming for 10 years and that one still confuses me! Most people just add parentheses to "fix" the problem. I wish someone would write an RFC to change this to right associative like every other language! *hint hint* Luke Scott On Apr 10, 2012, at 9:21 AM, Adir Kuhn wrote: > Hi folks, > > today I read this post, I think that some points are valid, follow the link > for > you guys > > http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ > > Adir Kuhn > ZCE - Zend Certified Engineer **PHP 5.3 #ZEND004035 > PSMI - Professional Scrum Master I -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Disabling PHP tags by php.ini and CLI options
Hey Rasmus, Here are my thoughts: On Apr 11, 2012, at 7:09 AM, Rasmus Lerdorf wrote: > On 04/11/2012 12:59 AM, Stas Malyshev wrote: >>> Therefore, it should not be misunderstood as perfect LFI >>> countermeasure even if I stressed on security meanings. >>> I'm stressing security because this actually helps PHP being >>> much safer than now. >> >> I don't see how it is "much safer". Exactly the same problem exists. Not >> only it is not "perfect" countermeasure, it's not countermeasure at all, >> judging from your description. It's like saying "I have SQL injection >> protection, but only if word "please" is not part of the SQL injection". >> It's not a real protection then. > > I guess he is saying that it prevents: > > Random bytes > > More random bytes > > Where random bytes might be an image file so finfo_file() might identify > it as a valid image whereas it doesn't prevent: > > > Random bytes > > from being mistakenly included. And I guess a secondary thing it might > prevent is an include of something like /etc/passwd since there is no > valid PHP code there and it would error out. Isn't this determined by the web server, not PHP? The only way this would happen is if image files were sent to the PHP interpreter or the image had a .php. In both cases it's the server admins responsibility to make sure the web server doesn't send any file from an upload folder to the PHP interpreter, with a .PHP extension or not. The programmer should also be mindful of what extensions are being allowed to go in the upload folder incase the server admin was negligent. The only benefit is only having to check the start of the file for a So, those are the pros. The cons are: > > 1. Creating a new mode for PHP that essentially breaks most existing PHP > code if this mode is enabled puts more pressure on people trying to > write portable code. It would encourage them to never use templating > mode since non-templating mode is the only safe approach that would work > regardless of the configuration. Much the same way that all portable > code uses is disallowed. Tom's RFC calls for template mode to remain the default, but allow you to add a flag to require/include to interpret the script in "pure mode". Allowing an optional starting in the middle of a class (which most people already do voluntarily). > 2. Templating is a defining characteristic of PHP. For many people it is > the primary reason they even use PHP. Adding a feature that would > essentially discourage use of a defining feature of PHP is illogical. True. People are side stepping this though for template engines such as Twig, PHPTAL, Smarty (ug..), just to name a few. PHP is being used more as a programming language than a template engine. People have already naturally gravitated towards keeping their code separate. Toms proposal of a code and template mode makes sense. It clearly separates the two. You could theoretically enhance the template part. Like I love the idea of PHPTAL - I wrote a similar template engine that uses attributes to convey logic (data-if, for example). Attribute syntax preserves the design of a template. Right now I have to parse this and convert this to a PHP class. Wouldn't it be great if PHP did this in its template mode? Or easily allowed people to provide alternate "template engines" that required no pre-parsing in PHP (other than the usual code to opcode transformation)? > 3. For the /etc/passwd case, the syntax error might reveal enough data > about the contents of the file that this doesn't actually provide enough > of a benefit unless we also heavily redact what we show in a syntax > error. Of course, the argument here is not to show the error to users, > but people who write code with include $_GET['filename'] aren't likely > to follow best practices in the first place. > > 4. Only protecting against mid-script injections and not top-of-script > injections is a somewhat subtle concept when the real problem is the > vulnerable include $_GET['filename'] hole. If this really is a prevalent > problem, maybe instead of trying to mitigate the symptoms, why don't we > try to attack the actual cause of the problem. I would love to hear some > ideas along those lines that don't fundamentally change the nature of > PHP for somewhat cloudy benefits. The problem is people are doing that. The solution is they should stop doing that. Anyone doing this is asking for trouble. The fix is better education. In the end while I do support the idea of not allowing "embed mode" (as a choice when doing require/include), I cannot support the idea that it somehow makes things more secure. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening
On Apr 10, 2012, at 6:59 PM, Tom Boutell wrote:
> On Tue, Apr 10, 2012 at 8:19 PM, Luke Scott wrote:
>> - I would like to see an INCLUDE_SILENT method to prevent warnings from
>> being thrown with include/include_once statements. Currently doing
>> something like @include "/path/to/file.php"; not only hides these
>> warnings, but warnings/errors/notices thrown by the file itself. An
>> INCLUDE_SILENT flag would be extremely helpful in some situations.
>
> I almost included this, but wasn't sure how you would actually become
> aware of the error at that point. class_exists is probably a valid
> answer to that. It would be dangerous to use the INCLUDE_SILENT for
> any include file that wasn't a class. The return value of 'include' is
> the return value of the code it executed, so we can't use that. How
> about INCLUDE_EXCEPTION?
That would be slightly better as you could then catch the exception.
But it doesn't make sense to do this in an auto loader because you'll
always be including classes. It would also add unnecessary overhead
having to catch the exception.
For me INCLUDE_BOTH is absolutely necessary.
Why not add both?
> This is really a separate issue, but it's true it would make a lot of
> sense to add this bit at the same time.
>
>> - The INCLUDE_ONCE and INCLUDE_ERROR_ON_FAILURE are a bit redundant.
>> Wouldn't you just use require or include_once/require_once?
>
> I like being able to do things dynamically without writing a switch
> statement. As we move toward having more bit flags, why not have the
> option of using flags for the existing distinctions as well (as long
> as you start with plain old 'include')?
I'm not sure it can be dynamic being a construct.
>> - Not sure I like the word "pure code". I would prefer just "code" -
>> INCLUDE_CODE. Perhaps even just "pure" - INCLUDE_PURE. I just don't like
>> two words. Would also like another flag for the other mode, such as
>> INCLUDE_TEMPLATE or INCLUDE_EMBED.
>
> These are bits, so INCLUDE_TEMPLATE would just be zero. Not sure it
> makes sense to have that as an explicit flag.
I suppose that makes sense. Still, could define it as zero.
>
>> - I would like to be able to specify the mode as an environmental variable
>> from the web server, perhaps "PHP_MODE". So I could do something like this
>> in my Nginx config:
>>
>> location / {
>>fastcgi_pass unix:/Server/tmp/php-fpm.sock;
>>includefastcgi_params;
>>fastcgi_param PHP_MODE "pure";
>>fastcgi_param SCRIPT_FILENAME $document_root/index.php;
>>fastcgi_param SCRIPT_NAME /index.php;
>>fastcgi_param HTTP_ACCEPT_ENCODING "";
>>fastcgi_param HTTPS $https;
>>}
>
> I almost included this too but I am a little fatigued thinking about
> all the details (:
>
> Can we arrange it so that .php and .phpp each do the right thing under
> fastcgi without creating two process pools? Is configuring FPM similar
> to configuring the classic CGI SAPI for FastCGI operation?
In order for it to work you need an environmental variable. You can
use the same pool, Nginx just needs a way to tell PHP what mode to use
for what extension.
In my case I'd configure Nginx to send all requests to Index.php in
pure mode, as I have shown in my config sample.
> A -p option for CLI and plain CGI is simple enough at least.
>
> I personally don't mind all that much if entry point PHP files don't
> get this feature but of course I see that others would like it. And
> one day it would be nice to alias phpp to php -p and write PHP one-off
> scripts without http://www.php.net/unsub.php
Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening
On 4/10/12 4:53 PM, "Tom Boutell" wrote:
>Please see:
>
>https://wiki.php.net/rfc/source_files_without_opening_tag
>
>After following the discussion I have updated the RFC with the
>following major changes:
>
>* Forbade the use of ?> entirely in "pure PHP" files (without
>restricting it at all in other PHP files)
>
>* Replaced my original new require_path keyword with a second,
>optional parameter to the standard include/require family of keywords
>
>* Replaced an array of options with a bitwise OR of options
>
>* Changed the proposed filename extension from .phpc (which apparently
>is in use somewhere, maybe?) to .phpp ("php pure")
Looks good, however:
- I would like to see an INCLUDE_SILENT method to prevent warnings from
being thrown with include/include_once statements. Currently doing
something like @include "/path/to/file.php"; not only hides these
warnings, but warnings/errors/notices thrown by the file itself. An
INCLUDE_SILENT flag would be extremely helpful in some situations.
Example:
if(class_exists("MyClass")) // Auto loader is used
{
// Class exists, continue normal...
}
else
{
// Class doesn't exist, do stuff... but warnings are being thrown!
Eeek!
}
(An INCLUDE_SILENT is probably the most important to me)
- The INCLUDE_ONCE and INCLUDE_ERROR_ON_FAILURE are a bit redundant.
Wouldn't you just use require or include_once/require_once?
- Not sure I like the word "pure code". I would prefer just "code" -
INCLUDE_CODE. Perhaps even just "pure" - INCLUDE_PURE. I just don't like
two words. Would also like another flag for the other mode, such as
INCLUDE_TEMPLATE or INCLUDE_EMBED.
- I would like to be able to specify the mode as an environmental variable
from the web server, perhaps "PHP_MODE". So I could do something like this
in my Nginx config:
location / {
fastcgi_pass unix:/Server/tmp/php-fpm.sock;
includefastcgi_params;
fastcgi_param PHP_MODE "pure";
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param SCRIPT_NAME /index.php;
fastcgi_param HTTP_ACCEPT_ENCODING "";
fastcgi_param HTTPS $https;
}
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Why is my library linking to the wrong path?
I'm using the line: PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD) Where the path is /phpdev/lib. But my extension is actually linking to /v8/out/x64.release/libv8.dylib instead of /phpdev/lib/libv8.dylib even though /v8/out/x64.release no longer exists. What am I doing wrong? Luke
[PHP-DEV] Re: Writing an extension - dyld: ...Symbol not found
> >> I'm writing an extension called "V8PHP". It's similar to the V8JS extension, >> but the implementation is quite different. >> >> ... >> >> Anyone know what the problem could be? >> >> Luke > > I figured out that v8 was being compiled in 32 bit mode... Apparently it > thinks "native" means 32 bit... Recompiled as 64 bit and now I'm getting this: > > PHP Warning: PHP Startup: Unable to load dynamic library > '/phpdev/lib/php/extensions/debug-zts-20090626/v8php.so' - > dlopen(/phpdev/lib/php/extensions/debug-zts-20090626/v8php.so, 9): Symbol not > found: __ZN2v88internal8Snapshot13context_size_E > Referenced from: /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so > Expected in: flat namespace > in /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so in Unknown on line > 0 > > > Luke Figured this out as well. I wasn't building the shared library for some reason... Luke
Re: [PHP-DEV] RFC: source files without opening tag
Tom, On Apr 10, 2012, at 6:48 AM, Tom Boutell wrote: > The "second part" in the RFC is just a suggested filename convention, > it is not a hardcoded requirement. I'm not sure that's what you're > talking about here. > > The RFC I'm referring to does not propose completely removing the > availability of the > https://wiki.php.net/rfc/source_files_without_opening_tag I would prefer to use the existing require/include/include_once/require_once keywords. Just add a second optional parameter to each. Also since these keywords are constructs it would be better to used or'd constants rather than an array. Luke > > On Tue, Apr 10, 2012 at 8:55 AM, Rafael Kassner wrote: >> IMHO, both parts can be separated. My personal opinion: the require_path >> with the php mode only can be useful, a mime type or extension for these >> files too, but I'm not sure about removing "> first part can be approved sooner than the second, or maybe the entire RFC >> would not be approved because the second. >> >> On Tue, Apr 10, 2012 at 9:35 AM, Tom Boutell wrote: >>> >>> An important clarification: the RFC has two parts, NOT two options. >>> Yasuo Ohgaki made many edits to the RFC before deciding to create his >>> own RFC. He backed out most of his edits but somewhere along the line >>> he introduced the words "Option 1" and "Option 2" for two things that >>> are meant to go tegether. The intention is to have both the new >>> functionality (the require_path keyword, or whatever that evolves >>> into) AND a strongly encouraged naming convention for PHP files of the >>> two types (see my original draft). >>> >>> I have corrected the RFC to read as intended. >>> >>> I'll be updating it with a second version shortly but wanted to clear >>> up this confusion first. >>> >>> (I think it would be best for RFCs to have a single author of group of >>> authors who are in agreement about the intent of the RFC. Proposing an >>> alternative RFC, as Yasuo Ohgaki is now doing, is a much less >>> confusing way to put forward a concept the original author does not >>> agree with.) >>> >>> -- >>> Tom Boutell >>> P'unk Avenue >>> 215 755 1330 >>> punkave.com >>> window.punkave.com >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> >> >> -- >> Atenciosamente, >> Rafael Kassner >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 10, 2012, at 12:24 AM, Flavius Aspra wrote: > On 04/09/2012 10:30 PM, Luke Scott wrote: >> Yeah it would be. He also mentioned something about preloading >> framework classes.. Would like to hear his thoughts on that! > > I also subscribe to the opinion of object persistency not being worth it. In > an application server, you could probably achieve more by keeping the entire > phar in RAM. > > Currently, you can also simulate that by putting the phar on a ramdisk or > similar. This is just the php code though isn't it? It still needs to be converted to opcodes, then executed. Is it possible to execute the phar in a "ready state" (before request, after init of several objects) and make a snapshot of that and use that for every request? (Shouldn't have to be a phar though.) Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 10:03 PM, Yasuo Ohgaki wrote: > I strongly discourage settingallow_url_include=on, too. Good. > Enabling it only when it is needed is okay. No it's not. There is no reason to do so other than backwards compatibility for very old code. > I think you are concerned about security, Absolutely. > so you could agree to have > option for disabling embedded mode by option, couldn't you? Sure it can be an option. But it can't be the default, at least right away. It's unreasonable. I would prefer an environmental variable to choose the mode though. I'm not opposed to a php.ini option, but some people are (If by embedded mode you mean template mode, and non-embedded mode as "pure code mode"). I still fail to see what this has to do with allow_url_include. > Letting programmers decide what to do Not in all cases. > Programming languages should give freedom to write suicide code > more or less. No, it shouldn't. All that you've said comes down to this: Don't write bad code. Configure your web server properly. The RFC isn't meant to address these issues, and quite frankly it isn't a core PHP issue. It's no different than any language with an eval() statement. Keep in mind an RFC isn't gospel. And it's still being drafted. We need to give Tom a chance to finish it. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 9:08 PM, Yasuo Ohgaki wrote: >> I would actually suggest that require/include stop supporting remote >> files all together. But that can be a different RFC. >> >> This "security problem" isn't a problem with common sense. > > Requiring/Including remote file is not bad, just like embedded mode > of PHP is not bad. You can fetch a remote file with curl, socket functions, he'll even file_get_contents. Point is you shouldn't be using require/include for including remote files. It's not the purpose of these functions, and even though "you can" it doesn't mean you should and it's highly discouraged. It's not a core PHP problem. It's programming problem. Where I work we forbid certain things like this for good reason. We also have a code review process. All code is checked by another developer before it gets commited. Even my code, and I'm a manager. This should be done at the very least. Some companies do this and then have a third party audit the code on top of it. > They are bad for security if they are enabled by default or mandatory. Again nothing has changed with this RFC. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
> It's easy to say "write correct code. don't write stupid code", but > we cannot enforce it in real world. > > I'm concerning both arbitrarily script execution and arbitrarily > information disclosure. Good example is LFI and SQL injection > attack. Uh yeah there is. I won't employ someone who insists on writing code like this. I dont know anyone who will. I also wont use libraries that have code like this. Not only is it insecure but an improper use of these constructs/functions. All this has nothing to do with Tom's RFC. It has nothing to do with having a http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 8:26 PM, Yasuo Ohgaki wrote:
> Hi,
>
> 2012/4/10 Luke Scott :
>> On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote:
>>
>>> Please don't repeat mistakes for allow_url_include or allow_url_include.
>>> If admin would like to enforce programmer not to change php.ini.
>>> They should use Apache httpd and admin_flag/admin_value.
>>>
>>> Programmers should have as much control as possible to be
>>> creative. Optional embedded mode is one of them. There are
>>> too many thing that programmers should worry. If it can be turned
>>> off, they are free from it.
>>
>> I'm not sure we're talking about the same thing. I'm really confused
>> about the objections.
>>
>> The ini options you mention are not mistakes. You should never be
>> using include/require for anything other than including local PHP
>> files. These constructs should have never supported remote files. That
>
> There is valid usage for allow_url_include=on.
>
> For instance, if both server and client is PHP, we could use var_export()
> to receive messages.
>
> Client
>
> include('http://server/send_my_data.php');
> ?>
>
>
> Server: /send_my_data.php
>
> echo "$response = ";
> var_export($some_useful_data);
> ?>
>
You should NEVER do this. There are much better ways of communicating
between servers.
Luke
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki wrote: > Please don't repeat mistakes for allow_url_include or allow_url_include. > If admin would like to enforce programmer not to change php.ini. > They should use Apache httpd and admin_flag/admin_value. > > Programmers should have as much control as possible to be > creative. Optional embedded mode is one of them. There are > too many thing that programmers should worry. If it can be turned > off, they are free from it. I'm not sure we're talking about the same thing. I'm really confused about the objections. The ini options you mention are not mistakes. You should never be using include/require for anything other than including local PHP files. These constructs should have never supported remote files. That was the mistake. The same goes for functions like file_get_contents - there are more appropriate ways of getting remote content. file_get_contents isn't nearly as bad though. ... But any of the above has nothing to do with this RFC. Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 7:44 PM, Yasuo Ohgaki wrote: > Hi, > > 2012/4/10 Luke Scott : >>>>> That said, allowing the skipping of an initial >>>> the file probably wouldn't be a big deal to implement in code mode. >>>> >>>> >>>> OK. If you can agree to this then I'm good. Perhaps only allow white space >>>> before it (which is ignored - everything else throws a parse error)? >>> >>> Great, that sounds doable. (This would be *allowing* a leading >> not *requiring* one. >> >> Great! Then it seems we both agree. >> >> As far as the require/include statement, have we pretty much settled >> on something like this: >> >> include "/foo/bar.php", INC_CODE; >> >> verses: >> >> include_path "/foo/bar.php"; >> > > These syntax does not help removing LFI risk in existing code > and allows novice to write suicide code. > > The only valid reason make mandatory embedded mode to > non mandatory is security. IMHO. > > BTW, although I'll vote opposing voice to have include_path() or > like, include_path() should be include_script(), shouldn't it? I'm not sure I fully understand your concern. require/include shouldn't be used for anything other than local php files. User input should also not be placed there. What am I missing? Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 6:22 PM, Kris Craig wrote: If the default is "template mode" and the " top) in "code" mode there shouldn't be any problems. > > We don't need to change or leave out the tag entirely. > > Is there a problem with people being able to choose "template mode" or > "code mode" as the default in the php.ini file if "template mode" is the > default if not specified? > I think so, yes. A config option that causes massive BC breakage doesn't become ok simply because it defaults to current behavior. I just can't envision any situation in which having that option switched on would not cause problems, unless that server is *only* running scripts that assume code mode. However, what if you want to use two scripts, but one assumes code and the other assumes HTML? The ini_set() function would be pretty much useless given the circumstances. Instead, I would have an optional
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 6:22 PM, Tom Boutell wrote: > On Mon, Apr 9, 2012 at 9:11 PM, Luke Scott wrote: >> Given that an autoloader just has the class name with the attached >> namespace, how is it to know whether or not to load a .php file or a .phpc >> file? I'm not going to add a stat in my autoloader (file_exists) just to >> check for the existence of one or the other. >> >> With APC I'm able to do apc.stat = 0. The stat happens once per file >> before the opcode is cached. After that no stats happen. Adding a >> file_exists bypasses this. > > This does not change. If you have cached the location of the .php > file, you can just as easily cache the location of the .phpc file. You > don't have to do a second stat either if your convention for that > library is that everything is .phpc. But even if you did do two stats, > it's only on the first pass - as long as you adopt the convention that > .phpc wins when present. No need to get crazy and look for otherwise > identically named .php and .phpc files and worry about which is newer > (: > > This is even more simply avoided by choosing a consistent convention > for a library of classes and not even looking for the other type for > that library. I don't cache the path and I wouldn't want to have to. My routes file simply has the controller class name. APC caches the path name and opcode. But I still have to choose _what_ goes in the require statement. I don't know about you, but my auto loader is extremely simple. Find the root namespace with strstr or strpos and check it in a registered namespace hash. A strtr to convert \ to /. Tack on a .php at the end and include. > >> Now as others have said: File extension is irrelevant. It's up to the web >> server to determine this. >> Not entirely sure everyone wants another extension though. Such things >> shouldn't be in the RFC since it's a web server thing anyway. > > First, it is not true that file extensions are irrelevant to the > actual PHP code. Every autoloader makes a file extension assumption > and gets no help from the web server. Of course. Mine assumes, and always will, .php. I probably will keep Second, proposing best practices to the community in an RFC makes > sense if they contribute to its successful adoption. There are, I > guess, environments in which extensions don't matter, but in most of > the real world, extensions do matter, and where they do matter, > consistency is helpful (: Thus a convention is proposed but not > enforced by the RFC. When things are worded this way we don't get > tripped up by the existence of edge cases where the convention can be > safely ignored. You aren't dictating best practices in an RFC. You're proposing an addition to the language. Best practices are discovered and agreed upon over time by the community. Separating HTML from code is already considered a best practice. The RFC assists in helping organizations enforce those practices (IF the choose to do so). >>> That said, allowing the skipping of an initial >> the file probably wouldn't be a big deal to implement in code mode. >> >> >> OK. If you can agree to this then I'm good. Perhaps only allow white space >> before it (which is ignored - everything else throws a parse error)? > > Great, that sounds doable. (This would be *allowing* a leading not *requiring* one. Great! Then it seems we both agree. As far as the require/include statement, have we pretty much settled on something like this: include "/foo/bar.php", INC_CODE; verses: include_path "/foo/bar.php"; ??? Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On 4/9/12 5:02 PM, "Kris Craig" wrote: >On Mon, Apr 9, 2012 at 4:47 PM, Tom Boutell wrote: > >> Let me be very clear about that... I am NOT proposing that > the top be mandatory in a file loaded in code mode! I don't want to >> type it ever again outside of a template file, personally. See the >> title of the RFC. >> > >But again, how then do you intend to make it so that a pure-code file can >be called directly from the webserver on a host where the developer >doesn't >have access to most config options? This is a very common scenario that >cannot be ignored. If not a to identify it as pure code otherwise this just isn't workable. > >Any INI option would be problematic because that would essentially cause >all scripts relying on the setting you didn't choose to break. And >unfortunately, recognizing a new file extension could pose problems for >people running on heavily restricted hosts that currently have PHP support >"built-in". While I would never host on one of those services myself, I >don't like the idea of suddenly alienating everyone who does. > >I'd totally be open to an alternative to the scrutiny, but so far I haven't seen one. And absent that, there's no way >I >could support this, which really sucks because at least conceptually I >think it's a really good idea. If the default is "template mode" and the " >--Kris > > > >> >> On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott wrote: >> > On 4/9/12 3:53 PM, "Tom Boutell" wrote: >> > >> >>I see why you want to allow > >>mode,' rather than disallowed in code mode. But your purpose is to >> >>allow legacy code to be autoloaded without knowing in advance whether >> >>it starts with > >> >> >>But that would probably lead in practice to the use of a single file >> >>extension for old and new class files. >> >> >> >>And that, in turn, would lead to source code being spewed to the >> >>browser for all to see if a perfectly respectable autoloader circa PHP >> >>5.3 runs into one of these new files. >> >> >> >>This is a much more significant security issue than some of those >> >>mentioned previously because perfectly well-written code would display >> >>this behavior if someone unknowingly drops a newer library into, say, >> >>the lib/ folder of a Symfony 1.4 project. Ouch. >> > >> > >> > So are you saying the starting "> > mode"? >> > >> > If so, I'm ok with that as long as: >> > >> > - "?>" is forbidden >> > >> > - Text before the opening > > either ignored or throws an error instead of printing to the output >> buffer. >> > >> > If that's not what you mean, please clarify. >> > >> > Luke >> > >> >> >> >>It would be much better for that autoloader to just ignore the file >> >>because it has a new extension. This way the problem is immediately >> >>apparent: >> >> >> >>"Hey, my class didn't load, something must be up. Oh my PHP is old >> >>and/or this autoloader doesn't know about .phpc files, what are they >> >>anyway... google google... aha, I need PHP 5.x and an updated >> >>autoloader. Grumble. Okay." >> >> >> >>This is a much safer outcome. >> >> >> >>On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote: >> >>> Tom, >> >>> >> >>> On 4/9/12 3:17 PM, "Tom Boutell" wrote: >> >>> >> >>>>My original goal was to stop typing > >>>>includes at the top. I think it's entirely reasonable to achieve it >> >>>>with an option to the require keywords for this purpose and a naming >> >>>>convention to be followed by autoloaders. Keep in mind how rarely >>you >> >>>>have to change them. We're talking about code maintained by a >> >>>>relatively small number of very sharp developers. They can handle a >> >>>>few flags (: >> >>>> >> >>>>The prohibition of ?> still seems unnecessary and perhaps divisive, >> >>>>but if it were preferable to the majority to prohibit ?> in a pure >> >>>>code file, I could live with that as long as classic PHP files are >> >>>>also 100% supported and remain the default. I'
Re: [PHP-DEV] RFC: source files without opening tag
On 4/9/12 5:38 PM, "Tom Boutell" wrote: >On Mon, Apr 9, 2012 at 8:27 PM, Luke Scott wrote: >> Tom, >> >> On 4/9/12 4:47 PM, "Tom Boutell" wrote: >> >>>Let me be very clear about that... I am NOT proposing that >>the top be mandatory in a file loaded in code mode! I don't want to >>>type it ever again outside of a template file, personally. See the >>>title of the RFC. >> >> And the problem is what exactly? Legacy code would be 5.4 code. PHP 5.3 >>is >> supported and code will be floating around for it for years to come. If >>I >> found a library on Github that was 5.4 compatible (starts with > don't want to remove the starting > it. Ideally I'd like to be able to check out that code without touching >>it. > >The RFC doesn't create this situation. .phpc files (by convention) >would be loaded in code-first mode, .php files (your existing 5.4 >libraries) would be loaded in html-first mode. So the backwards >compatibility problem you describe doesn't exist in the RFC. Given that an autoloader just has the class name with the attached namespace, how is it to know whether or not to load a .php file or a .phpc file? I'm not going to add a stat in my autoloader (file_exists) just to check for the existence of one or the other. With APC I'm able to do apc.stat = 0. The stat happens once per file before the opcode is cached. After that no stats happen. Adding a file_exists bypasses this. Now as others have said: File extension is irrelevant. It's up to the web server to determine this. > >> Leaving out the starting >if >> loading code with an older version of PHP. An older version of PHP is >> going to see this code as plain text printed to the browser. In fact I >> would probably make sure my config files ALWAYS started with a > to ensure passwords were safe. > >This would only be done in .phpc files, and those creating code for >reuse elsewhere would probably only use .phpc files in libraries of >reusable classes etc. Best practices put these outside the document >root where Apache would not have the potential to serve them. I would hope these files are outside the document root (I use Nginx, so they are). But not everyone does this unfortunately. >Of course in a pure PHP 5.x environment you could choose to configure >Apache to serve .phpc files directly but I realize it would be a long >time before anyone considered it best practice to write entry point >.php files or PHP files containing passwords as .phpc files. Which is >fine, because it is not a common practice to have more than one or two >such in an entire framework-based application. Not entirely sure everyone wants another extension though. Such things shouldn't be in the RFC since it's a web server thing anyway. >That said, allowing the skipping of an initial the file probably wouldn't be a big deal to implement in code mode. OK. If you can agree to this then I'm good. Perhaps only allow white space before it (which is ignored - everything else throws a parse error)? Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Tom, On 4/9/12 4:47 PM, "Tom Boutell" wrote: >Let me be very clear about that... I am NOT proposing that the top be mandatory in a file loaded in code mode! I don't want to >type it ever again outside of a template file, personally. See the >title of the RFC. See below. > >On Mon, Apr 9, 2012 at 7:06 PM, Luke Scott wrote: >> On 4/9/12 3:53 PM, "Tom Boutell" wrote: >> >>>I see why you want to allow >>mode,' rather than disallowed in code mode. But your purpose is to >>>allow legacy code to be autoloaded without knowing in advance whether >>>it starts with >>But that would probably lead in practice to the use of a single file >>>extension for old and new class files. >>> >>>And that, in turn, would lead to source code being spewed to the >>>browser for all to see if a perfectly respectable autoloader circa PHP >>>5.3 runs into one of these new files. >>> >>>This is a much more significant security issue than some of those >>>mentioned previously because perfectly well-written code would display >>>this behavior if someone unknowingly drops a newer library into, say, >>>the lib/ folder of a Symfony 1.4 project. Ouch. Leaving out the starting is forbidden in "code mode". Both are usable in "template mode". Behavior is changed by constants next to require/include. Everybody wins, right? Luke >>>> >>>> >>>> I think you can you achieve that by making "template mode" default and >>>>the >>>> default changeable in the php.ini file. >>>> >>>> Something like this: >>>> >>>> /* >>>>Code only, . >>>>Text before opening >>> >>>> */ >>>> >>>> require "/path/to/somefile.php", INCLUDE_CODE; >>>> >>>> /* >>>>Works exactly as it is now: allowed. >>>>Text betweeen ?>...>>> */ >>>> >>>> >>>> >>>> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now >>>> >>>> /* >>>>By default INCLUDE_TEMPLATE >>>>Can change default mode in php.ini to be INCLUDE_CODE if desired. >>>> */ >>>> >>>> require "/path/to/anotherfile.php"; // As it is now >>>> >>>> >>>> Personally I would like to be able to do something like this in my >>>>auto >>>> loader: >>>> >>>> include $file, INCLUDE_CODE & INCLUDE_SILENT; >>>> >>>> >>>> >>>> That way I can ensure pure code is being inserted and no warnings are >>>> thrown if the file doesn't exist (class undefined will be thrown >>>>anyway). >>>> >>>> I think it's important to make >>>using >>>> existing or third party libraries that you can't modify. At least then >>>> you'll be able to maintain backwards compatibility with most code >>>>written >>>> since PHP 5. >>>> >>>> (We don't need PHP_*. See the output of get_defined_constants() ). >>>> >>>> I like where this is going! Hopefully after the RFC has been finalized >>>> everyone else will agree. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Writing an extension - dyld: ...Symbol not found
> I'm writing an extension called "V8PHP". It's similar to the V8JS extension, > but the implementation is quite different. > > ... > > Anyone know what the problem could be? > > Luke I figured out that v8 was being compiled in 32 bit mode... Apparently it thinks "native" means 32 bit... Recompiled as 64 bit and now I'm getting this: PHP Warning: PHP Startup: Unable to load dynamic library '/phpdev/lib/php/extensions/debug-zts-20090626/v8php.so' - dlopen(/phpdev/lib/php/extensions/debug-zts-20090626/v8php.so, 9): Symbol not found: __ZN2v88internal8Snapshot13context_size_E Referenced from: /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so Expected in: flat namespace in /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so in Unknown on line 0 Luke
Re: [PHP-DEV] RFC: source files without opening tag
> On Mon, Apr 9, 2012 at 3:34 PM, Luke Scott wrote: >> Tom, >> >> On 4/9/12 3:17 PM, "Tom Boutell" wrote: >> >>> >My original goal was to stop typing >> >includes at the top. I think it's entirely reasonable to achieve it >>> >with an option to the require keywords for this purpose and a naming >>> >convention to be followed by autoloaders. Keep in mind how rarely you >>> >have to change them. We're talking about code maintained by a >>> >relatively small number of very sharp developers. They can handle a >>> >few flags (: > > Again though, the problem here is that you're relying on the including script > to determine whether a PHP script is pure or not; i.e. this approach leaves no > way for that to be determined in the file itself. For example, I can see > perfectly valid instances where it would be ideal to execute one of these pure > scripts as a direct call to the webserver-- AJAX being a prime example. I.e. > cases where you want backend PHP processing to take place but it has to be > accessed via the browser (most likely "hidden" as an AJAX query though). > > So without the ability to do that, I just don't think this passes the > usefulness test for me. And if we do have the ability to specify that in the > file, on the other hand, then that would pretty much eliminate the need for a > require flag anyway. > > The only alternative I can see would be to allow something to be passed in the > headers telling the webserver to parse a script as PHP instead of HTML. But I > don't know if that would be extremely simple or extremely problematic. If the default mode was configured in the php.ini file (code mode vs template mode) wouldn't the web server use that? The web server is pretty much doing this: require "/path/to/somefile.php". Luke > > > --Kris > > >>> > >>> >The prohibition of ?> still seems unnecessary and perhaps divisive, >>> >but if it were preferable to the majority to prohibit ?> in a pure >>> >code file, I could live with that as long as classic PHP files are >>> >also 100% supported and remain the default. I'm trying to craft a >>> >broadly acceptable compromise that still achieves the original goal of >>> >allowing people to write "just code" in a class file. >> >> >> I think you can you achieve that by making "template mode" default and the >> default changeable in the php.ini file. >> >> Something like this: >> >> /* >> Code only, . >> Text before opening > >> */ >> >> require "/path/to/somefile.php", INCLUDE_CODE; >> >> /* >> Works exactly as it is now: allowed. >> Text betweeen ?>...> */ >> >> >> >> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now >> >> /* >> By default INCLUDE_TEMPLATE >> Can change default mode in php.ini to be INCLUDE_CODE if desired. >> */ >> >> require "/path/to/anotherfile.php"; // As it is now >> >> >> Personally I would like to be able to do something like this in my auto >> loader: >> >> include $file, INCLUDE_CODE & INCLUDE_SILENT; >> >> >> >> That way I can ensure pure code is being inserted and no warnings are >> thrown if the file doesn't exist (class undefined will be thrown anyway). >> >> I think it's important to make > existing or third party libraries that you can't modify. At least then >> you'll be able to maintain backwards compatibility with most code written >> since PHP 5. >> >> (We don't need PHP_*. See the output of get_defined_constants() ). >> >> I like where this is going! Hopefully after the RFC has been finalized >> everyone else will agree. >> >> >>> > >>> >On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote: >> >> >> Kris, >> >> >> >>>> >> >>>> >> >>>> >> Bah, right! That damned >>> >> >>>> >> I already know what everyone's reaction will be, and it is probably a >>>> >>REALLY >>>> >> bad idea, but I feel obligated to at least mention it: Should we >>>> >>consider >>>> >> replacing ">>> >> perhaps starting in PHP 6? No need to get out the torches and >>>> >>pitchforks, >>>> >> everyone! As insane and problematic as that would be (i.e. BC break >>>> >>with >>>> >> roughly 1/3 of the internet lol), I felt as though the subject should at >>>> >> least be broached. ;P >> >> >> No need. Just keep it as > should ovoid overcomplicating it. >> >> Luke >> >> >
Re: [PHP-DEV] RFC: source files without opening tag
On 4/9/12 3:53 PM, "Tom Boutell" wrote: >I see why you want to allow mode,' rather than disallowed in code mode. But your purpose is to >allow legacy code to be autoloaded without knowing in advance whether >it starts with >But that would probably lead in practice to the use of a single file >extension for old and new class files. > >And that, in turn, would lead to source code being spewed to the >browser for all to see if a perfectly respectable autoloader circa PHP >5.3 runs into one of these new files. > >This is a much more significant security issue than some of those >mentioned previously because perfectly well-written code would display >this behavior if someone unknowingly drops a newer library into, say, >the lib/ folder of a Symfony 1.4 project. Ouch. So are you saying the starting "" is forbidden - Text before the opening >It would be much better for that autoloader to just ignore the file >because it has a new extension. This way the problem is immediately >apparent: > >"Hey, my class didn't load, something must be up. Oh my PHP is old >and/or this autoloader doesn't know about .phpc files, what are they >anyway... google google... aha, I need PHP 5.x and an updated >autoloader. Grumble. Okay." > >This is a much safer outcome. > >On Mon, Apr 9, 2012 at 6:34 PM, Luke Scott wrote: >> Tom, >> >> On 4/9/12 3:17 PM, "Tom Boutell" wrote: >> >>>My original goal was to stop typing >>includes at the top. I think it's entirely reasonable to achieve it >>>with an option to the require keywords for this purpose and a naming >>>convention to be followed by autoloaders. Keep in mind how rarely you >>>have to change them. We're talking about code maintained by a >>>relatively small number of very sharp developers. They can handle a >>>few flags (: >>> >>>The prohibition of ?> still seems unnecessary and perhaps divisive, >>>but if it were preferable to the majority to prohibit ?> in a pure >>>code file, I could live with that as long as classic PHP files are >>>also 100% supported and remain the default. I'm trying to craft a >>>broadly acceptable compromise that still achieves the original goal of >>>allowing people to write "just code" in a class file. >> >> >> I think you can you achieve that by making "template mode" default and >>the >> default changeable in the php.ini file. >> >> Something like this: >> >> /* >>Code only, . >>Text before opening > >> */ >> >> require "/path/to/somefile.php", INCLUDE_CODE; >> >> /* >>Works exactly as it is now: allowed. >>Text betweeen ?>...> */ >> >> >> >> require "/path/to/anotherfile.php", INCLUDE_TEMPLATE; // As it is now >> >> /* >>By default INCLUDE_TEMPLATE >>Can change default mode in php.ini to be INCLUDE_CODE if desired. >> */ >> >> require "/path/to/anotherfile.php"; // As it is now >> >> >> Personally I would like to be able to do something like this in my auto >> loader: >> >> include $file, INCLUDE_CODE & INCLUDE_SILENT; >> >> >> >> That way I can ensure pure code is being inserted and no warnings are >> thrown if the file doesn't exist (class undefined will be thrown >>anyway). >> >> I think it's important to make > existing or third party libraries that you can't modify. At least then >> you'll be able to maintain backwards compatibility with most code >>written >> since PHP 5. >> >> (We don't need PHP_*. See the output of get_defined_constants() ). >> >> I like where this is going! Hopefully after the RFC has been finalized >> everyone else will agree. >> >> >>> >>>On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote: >> >> >> Kris, >> >> >> >>>> >>>> >>>> Bah, right! That damned >>> >>>> I already know what everyone's reaction will be, and it is probably a >>>>REALLY >>>> bad idea, but I feel obligated to at least mention it: Should we >>>>consider >>>> replacing ">>> perhaps starting in PHP 6? No need to get out the torches and >>>>pitchforks, >>>> everyone! As insane and problematic as that would be (i.e. BC break >>>>with >>>> roughly 1/3 of the internet lol), I felt as though the subject should >>>>at >>>> least be broached. ;P >> >> >> No need. Just keep it as > should ovoid overcomplicating it. >> >> Luke >> >> > > > >-- >Tom Boutell >P'unk Avenue >215 755 1330 >punkave.com >window.punkave.com > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Tom, On 4/9/12 3:17 PM, "Tom Boutell" wrote: >My original goal was to stop typing includes at the top. I think it's entirely reasonable to achieve it >with an option to the require keywords for this purpose and a naming >convention to be followed by autoloaders. Keep in mind how rarely you >have to change them. We're talking about code maintained by a >relatively small number of very sharp developers. They can handle a >few flags (: > >The prohibition of ?> still seems unnecessary and perhaps divisive, >but if it were preferable to the majority to prohibit ?> in a pure >code file, I could live with that as long as classic PHP files are >also 100% supported and remain the default. I'm trying to craft a >broadly acceptable compromise that still achieves the original goal of >allowing people to write "just code" in a class file. I think you can you achieve that by making "template mode" default and the default changeable in the php.ini file. Something like this: /* Code only, . Text before opening allowed. Text betweeen ?>... >On Mon, Apr 9, 2012 at 6:06 PM, Kris Craig wrote: Kris, >> >> >> Bah, right! That damned > >> I already know what everyone's reaction will be, and it is probably a >>REALLY >> bad idea, but I feel obligated to at least mention it: Should we >>consider >> replacing "> perhaps starting in PHP 6? No need to get out the torches and >>pitchforks, >> everyone! As insane and problematic as that would be (i.e. BC break >>with >> roughly 1/3 of the internet lol), I felt as though the subject should at >> least be broached. ;P No need. Just keep it as http://www.php.net/unsub.php
[PHP-DEV] Writing an extension - dyld: ...Symbol not found
I'm writing an extension called "V8PHP". It's similar to the V8JS extension, but the implementation is quite different. I'm having trouble linking the v8 library to my extension. When I run a PHP script via CLI I get: dyld: lazy symbol binding failed: Symbol not found: __ZN2v86String3NewEPKci Referenced from: /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so Expected in: flat namespace dyld: Symbol not found: __ZN2v86String3NewEPKci Referenced from: /phpdev/lib/php/extensions/debug-zts-20090626/v8php.so Expected in: flat namespace Trace/BPT trap I have PHP installed in /phpdev/ (--prefix=/phpdev). v8 was compiled with gyp using the following commands: cd /v8/ make dependencies make native And this outputted these files to /v8/out/native/: libpreparser_lib.a libv8_base.a libv8_nosnapshot.a libv8_snapshot.a obj/ obj.target/ And the obj.target directory has a bunch of .a files in obj.target/v8_base/src/. I created a soft link from /v8/include/v8.h to /phpdev/include/v8.h, /v8/include/v8stdint.h to /phpdev/include/v8stdint.h, and /v8/out/native/libv8_base.a to /phpdev/lib/libv8.a. My config.m4 file looks like this: PHP_ARG_ENABLE(v8php, [V8PHP], [--enable-v8php Include V8 JavaScript Engine]) if test $PHP_V8PHP != "no"; then SEARCH_PATH="$prefix /usr/local /usr" SEARCH_FOR="/include/v8.h" if test -r $PHP_V8PHP/$SEARCH_FOR; then V8_DIR=$PHP_V8PHP else AC_MSG_CHECKING([for V8 files in default path]) for i in $SEARCH_PATH ; do if test -r $i/$SEARCH_FOR; then V8_DIR=$i AC_MSG_RESULT(found in $i) fi done fi if test -z "$V8_DIR"; then AC_MSG_RESULT([not found]) AC_MSG_ERROR([Unable to locate V8]) fi PHP_ADD_INCLUDE($V8_DIR/include) PHP_ADD_LIBRARY_WITH_PATH(v8, $V8_DIR/$PHP_LIBDIR, V8PHP_SHARED_LIBADD) PHP_SUBST(V8PHP_SHARED_LIBADD) PHP_REQUIRE_CXX() PHP_NEW_EXTENSION(v8php, v8php.cc v8_class.cc, $ext_shared) fi It _seems_ like libv8.a is trying to link to something else... but I'm not sure. My extension compiled fine. I'm on Mac OS X 10.6.x. Anyone know what the problem could be? Luke
Re: [PHP-DEV] RFC: source files without opening tag
> Obviously, it would need to be at the top of the PHP file (whitespace > notwithstanding). Since we don't want any BC breaks, we at very least need > it to start with " mean to be parsed. So how about we keep it simple and just use a single, > " would be allowed after that. > Anything before that (in the file itself) would also be ignored and throw a > warning. Remember, This sounds like the best approach, given the limitations involved with > webserver configurations. I'm still very much against though allowing ?> > within one of these files (included or otherwise), as it really defeats the > whole purpose and would just encourage poor architecture without any > countervailing benefit. Agreed. Disallowing ?> in a file in pure code means only one > --Kris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
Pierre, On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote: > Something I have been discussed in the past with a couple of persons > is to have a mechanism to automatically instantiate objects on request > start. That's not persistent objects but that could already boost a > little it the base foot print of some frameworks. Would you be able to go into more detail on how this would be implemented? Could something like this be done with a zend extension? Would it involve loading a "loader.php" file and then taking a snapshot of the memory state, or something like that (before loading the actual file index.php file, similar to the prepend feature)? Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 9, 2012, at 7:49 AM, Flavius Aspra wrote: > On 04/07/2012 05:21 AM, Luke Scott wrote: >> From what I've gathered thus far, it is impossible to do without copying the >> >> non-persistent memory into persistent memory, and then back again. > > Hi, glad to see you again StackOverflow user:-) > > I think I've shown you the route by that [1] project, and yes, the emalloc() > call is hardcoded in so many places that you'd have to do it this way. The problem with that is serialization. You can pretty much do the same thing with APC. > > But as Pierre said, an application server for PHP (PHP-FPM?) would be great. > The stub part of a .phar file could play a big role there. Yeah it would be. He also mentioned something about preloading framework classes.. Would like to hear his thoughts on that! Luke > > Regards, > Flavius > > [1] https://github.com/flavius/php-persist > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Tom, On Apr 9, 2012, at 11:26 AM, Tom Boutell wrote: > Ralph, you make good points. And Luke's opposition to my new keyword > is probably going to be shared by others (like Chris who just chimed > in). > > So the more I think about it, the more a set of constants that can be > OR'd together is a better idea than my associative array proposal. And > it's best to keep the original four keywords, adding the second, > optional parameter as a way of passing a combination of flags that > alter their behavior. > > Also that set of bits could include the 'once' and 'warning' flags, so > if you really want to just use the 'require' keyword and determine > dynamically which behavior you get, you can. So there are no new > keywords needed. > > Also, the presence of any bit that is not recognized by this version > of PHP should be an error. It's better to stop than to completely > misparse a file (: > > I don't think long-ish constants are a real problem since this > functionality would very likely be written just a few times in > autoloaders (as is typical in almost any project that would be > interested in .phpc files in the first place) rather than repeatedly > all over the place in every file (as with old-fashioned uses of > 'require', and various templating situations). > > I will revise the RFC shortly I do like constants. I would recommend: CODE TEMPLATE SILENT ...with some sort of prefix like INCLUDE_* or INC_*. I would very much like to have the ability to prevent just the warnings generated by include... Primarily for an auto loader. Include/require supports include path, file_exists does not. You can avoid a stat on include/require with APC, with file_exists you cannot. Perhaps that belongs in a different RFC... But if we're thinking of using constants it would be a nice thing to mention. Luke > > On Mon, Apr 9, 2012 at 1:51 PM, Luke Scott wrote: >> On Apr 9, 2012, at 10:44 AM, Ralph Schindler >> wrote: >> >>> Hey Tom, >>> >>> An idea, why not overload require/include with a second parameter that >>> simply enforces an include mode. For example >>> >>> // in some autoloader (include, requires, and *_onces) >>> include $pathToFile, INCLUDE_MODE_PHP_ONLY; >>> >>> This would tell the parser/executor to start in PHP mode and never leave >>> it, that way, ending tags would throw a runtime/execution error. >>> >>> Other constants and behaviors could be: >>> >>> INCLUDE_MODE_PHP_START; >>> INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior) >>> >>> This would have the least amount of impact on BC, and seeminlyg would be a >>> friendly change to the lexer/syntax. >>> >>> Thoughts? >> >> >> If this were to happen: >> >> - I would prefer much shorter elegant constants. >> >> - A constant for suppressing warnings thrown by include without >> suppressing warnings/errors by the actual file -- I think we can all >> agree @include is counter productive since it does much more that >> suppress warnings thrown by include (even parse errors!). >> >> Luke >> >> >>> >>> -ralph >>> >>> >>> >>> On 4/9/12 12:23 PM, Tom Boutell wrote: >>>> Also, your objection - that 'require_code' is confusing - would most >>>> likely be an issue for a handful of people who write autoloaders. >>>> Those clean PHP class files are almost always autoloaded. >>>> >>>> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell wrote: >>>>> I see what you're saying, but you're proposing a new keyword to >>>>> include code that does what plain old 'require' does now (assuming >>>>> it's not a nice clean class file that is being included). Which means >>>>> that valid code today is busted code once this feature comes out. That >>>>> seems like a very hard sell. >>>>> >>>>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott wrote: >>>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell wrote: >>>>>> >>>>>>> It sounds like you are proposing to gradually kill the use of PHP for >>>>>>> templating entirely, which I don't think is something people would >>>>>>> vote for. >>>>>> >>>>>> I'm not saying that at all. I'm saying that PHP code should be clearly >>>>>> separated from template code.>>
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 12:16 PM, "Ángel González" wrote:
> On 09/04/12 20:23, Chris Stockton wrote:
>> Hello,
>> Although I am not very interested in this feature, if it is
>> implemented I like the idea of flags instead of introducing new
>> keywords. Maintaining backwards compatibility would be great
>> considering the benefit to the feature to be completely honest (and in
>> disagreement to many people, but I do understand the reasoning for
>> everyone's interest in it) is extremely minor in my eyes.
>>
>> In addition I would suggest maybe using PHP_INCLUDE_* as a place for
>> these constants to live.
>>
>> -Chris
> That would still be a parse error.
> Either
> include "file.php", 5;
> or
> include ("file.php", 42);
>
> Fails with a parse error about unexpected ','
>
> On the other hand, a new keyword can be written in a backwards
> compatible way by making it look like a function call in a non-taken branch:
The keyword "abstract" would cause a parse error for older versions of
PHP. Backwards compatibility is having existing code work with the
current versions.
To make new code compatible with older versions of PHP you simply
don't use the keyword/constant.
>
> *if ( version_compare(PHP_VERSION*, '5.5', '<') )
> include_once $file;
> else
> require_code($file, array( 'once'=>true, 'warn' => 'ignore' ) );
I'm fairly certain that wouldn't work either. Require and friends are
constructs, not functions.
Luke
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 12:27 PM, "Ángel González" wrote: > On 09/04/12 19:36, Luke Scott wrote: >> On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote: >>> Also, your objection - that 'require_code' is confusing - would most >>> likely be an issue for a handful of people who write autoloaders. >>> Those clean PHP class files are almost always autoloaded. >> Not really. Has nothing to do with auto loaders. >> >> require_code - A literal string? Is this eval? >> >> require_path - A directory? >> >> require_file - What kind of file? > A php file, of course :) I'm sorry but the word "file" is highly non descriptive. Remember to consider newcomers to the language as well. Consider also the are functions that already make use of this word such as: file, file_get_contents, file_put_contents, readfile, etc... > > >> You have to look at the keywords you're proposing and try to explain >> then without prior knowledge or documentation. > But if you come accross them you'd see something like: > require_code "setup.php"; > > Which is much more clear. You also can't make the assumption that someone is going to learn this from existing code. > >> These keywords are also ambiguous. require/include are well understood >> for including code not templates. Not just for PHP. > PHP has allowed to require HTML forever. Given it's php developers the main > target, it is not a huge argument that they may get confused by > require_file > doing what require has always done. And it's considered bad practice. A majority of PHP developers avoid it. The only time they do this is for templates in very small projects. For larger projects using PHP as a template engine is unmaintainable. If you look at code on Github I'm sure you'll find most code starting with at the end... But even fewer are going to break out of PHP just to print something. Especially with nowdoc. We aren't trying to be compatible with PHP 4. Most of what I have said has been the case since PHP 5.1. At least 5.2 (which is no longer supported). Luke > > I admit require_code for a full HTML file* may be slightly odd, but > require_file > is completely aseptic about that. > > > * Which should instead have been loaded with readfile()... > > >> require_template on the other hand is clear and to the point. It's >> hard to make the same kind of assumptions as you can with the other >> keywords. And with those who know PHP it's readily apparent >> require_template could mean short tags whereas the other leave you >> scratching your head. > Except that you're breaking compatibility by designing it the opposite way. > It may have been the perfect idea if we were designing PHP from scratch, but > we're not. This is a 17 years old language. > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 10:44 AM, Ralph Schindler wrote:
> Hey Tom,
>
> An idea, why not overload require/include with a second parameter that simply
> enforces an include mode. For example
>
> // in some autoloader (include, requires, and *_onces)
> include $pathToFile, INCLUDE_MODE_PHP_ONLY;
>
> This would tell the parser/executor to start in PHP mode and never leave it,
> that way, ending tags would throw a runtime/execution error.
>
> Other constants and behaviors could be:
>
> INCLUDE_MODE_PHP_START;
> INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior)
>
> This would have the least amount of impact on BC, and seeminlyg would be a
> friendly change to the lexer/syntax.
>
> Thoughts?
If this were to happen:
- I would prefer much shorter elegant constants.
- A constant for suppressing warnings thrown by include without
suppressing warnings/errors by the actual file -- I think we can all
agree @include is counter productive since it does much more that
suppress warnings thrown by include (even parse errors!).
Luke
>
> -ralph
>
>
>
> On 4/9/12 12:23 PM, Tom Boutell wrote:
>> Also, your objection - that 'require_code' is confusing - would most
>> likely be an issue for a handful of people who write autoloaders.
>> Those clean PHP class files are almost always autoloaded.
>>
>> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell wrote:
>>> I see what you're saying, but you're proposing a new keyword to
>>> include code that does what plain old 'require' does now (assuming
>>> it's not a nice clean class file that is being included). Which means
>>> that valid code today is busted code once this feature comes out. That
>>> seems like a very hard sell.
>>>
>>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott wrote:
>>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell wrote:
>>>>
>>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>>> templating entirely, which I don't think is something people would
>>>>> vote for.
>>>>
>>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>>> separated from template code.>>> the file and IF a keyword should be added it should be for templates
>>>> and short-tags.
>>>>
>>>> 99% of modern PHP code is going to be classes that start with>>> and omit the ending ?> (since PHP 5 due to how easy it is for white
>>>> space to end up on the tail end of a file). this is even the case with
>>>> procedural code.
>>>>
>>>> Half the PHP frameworks out there have their own template engine
>>>> because they can do a lot more than what short tags offer. Example:
>>>> Twig offers template inheritance.
>>>>
>>>> Introducing a keyword for PHP code without the>>> impractical. It makes much more sense to have a keyword for templates.
>>>>
>>>> For non-template code the starting>>> has before for backwards compatibility. The difference is you cannot
>>>> use ?> and text before the opening>>> throws an error.
>>>>
>>>>> I sometimes use perfectly good older frameworks that do use
>>>>> .php files for templating in a reasonable way, and I'm one of the
>>>>> advocates for migrating away from starting everything with>>>> would have to vote against it myself.
>>>>
>>>> And those files can be included with something like require_template
>>>> or you can turn off the option in the ini file.
>>>>
>>>> The point is in EITHER MODE a php file that starts with>>> work as it did before. The new mode would just disallow you to break
>>>> out of PHP code with ?>.
>>>>
>>>>> There's no reason to kill good
>>>>> code that passes its tests just because it uses inline HTML. I won't
>>>>> even know I have that code in my project from some third party library
>>>>> until I find out the hard way. No, just no. (:
>>>>
>>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>>> smooth transition to something that is already done. The difference is
>>>> at some point you won't be able to do this:
>>>>
>>>> >>> class Object
>>>> {
>>>>public function output()
>>>>{
>>>> ?>
>>>> Print me!
>>>> >>&
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 10:23 AM, Tom Boutell wrote:
> Also, your objection - that 'require_code' is confusing - would most
> likely be an issue for a handful of people who write autoloaders.
> Those clean PHP class files are almost always autoloaded.
Not really. Has nothing to do with auto loaders.
require_code - A literal string? Is this eval?
require_path - A directory?
require_file - What kind of file?
You have to look at the keywords you're proposing and try to explain
then without prior knowledge or documentation.
These keywords are also ambiguous. require/include are well understood
for including code not templates. Not just for PHP.
require_template on the other hand is clear and to the point. It's
hard to make the same kind of assumptions as you can with the other
keywords. And with those who know PHP it's readily apparent
require_template could mean short tags whereas the other leave you
scratching your head.
Luke
>
> On Mon, Apr 9, 2012 at 1:22 PM, Tom Boutell wrote:
>> I see what you're saying, but you're proposing a new keyword to
>> include code that does what plain old 'require' does now (assuming
>> it's not a nice clean class file that is being included). Which means
>> that valid code today is busted code once this feature comes out. That
>> seems like a very hard sell.
>>
>> On Mon, Apr 9, 2012 at 1:10 PM, Luke Scott wrote:
>>> On Apr 9, 2012, at 9:16 AM, Tom Boutell wrote:
>>>
>>>> It sounds like you are proposing to gradually kill the use of PHP for
>>>> templating entirely, which I don't think is something people would
>>>> vote for.
>>>
>>> I'm not saying that at all. I'm saying that PHP code should be clearly
>>> separated from template code. >> the file and IF a keyword should be added it should be for templates
>>> and short-tags.
>>>
>>> 99% of modern PHP code is going to be classes that start with >> and omit the ending ?> (since PHP 5 due to how easy it is for white
>>> space to end up on the tail end of a file). this is even the case with
>>> procedural code.
>>>
>>> Half the PHP frameworks out there have their own template engine
>>> because they can do a lot more than what short tags offer. Example:
>>> Twig offers template inheritance.
>>>
>>> Introducing a keyword for PHP code without the >> impractical. It makes much more sense to have a keyword for templates.
>>>
>>> For non-template code the starting >> has before for backwards compatibility. The difference is you cannot
>>> use ?> and text before the opening >> throws an error.
>>>
>>>> I sometimes use perfectly good older frameworks that do use
>>>> .php files for templating in a reasonable way, and I'm one of the
>>>> advocates for migrating away from starting everything with >>> would have to vote against it myself.
>>>
>>> And those files can be included with something like require_template
>>> or you can turn off the option in the ini file.
>>>
>>> The point is in EITHER MODE a php file that starts with >> work as it did before. The new mode would just disallow you to break
>>> out of PHP code with ?>.
>>>
>>>> There's no reason to kill good
>>>> code that passes its tests just because it uses inline HTML. I won't
>>>> even know I have that code in my project from some third party library
>>>> until I find out the hard way. No, just no. (:
>>>
>>> I'm not trying to kill anything. In fact what I'm proposing would be a
>>> smooth transition to something that is already done. The difference is
>>> at some point you won't be able to do this:
>>>
>>> >> class Object
>>> {
>>>public function output()
>>>{
>>> ?>
>>> Print me!
>>> >>}
>>> }
>>>
>>> I cringe every time I see this. There is no excuse since we have
>>> here/nowdocs.
>>>
>>> For people that use PHP as a template there can be other options. I'm
>>> not totally against a new keyword, but I am against a new keyword for
>>> including normal PHP code. It just doesn't make sense. No matter what
>>> you name it (require_code, require_file, require_path) it's damned
>>> confusing. If you did it the other way around its much clearer:
>>> require_template.
>>>
>>> With require_template you're also free to expand template
&g
Re: [PHP-DEV] RFC: source files without opening tag
On Apr 9, 2012, at 9:16 AM, Tom Boutell wrote: > It sounds like you are proposing to gradually kill the use of PHP for > templating entirely, which I don't think is something people would > vote for. I'm not saying that at all. I'm saying that PHP code should be clearly separated from template code. (since PHP 5 due to how easy it is for white space to end up on the tail end of a file). this is even the case with procedural code. Half the PHP frameworks out there have their own template engine because they can do a lot more than what short tags offer. Example: Twig offers template inheritance. Introducing a keyword for PHP code without the and text before the opening I sometimes use perfectly good older frameworks that do use > .php files for templating in a reasonable way, and I'm one of the > advocates for migrating away from starting everything with would have to vote against it myself. And those files can be included with something like require_template or you can turn off the option in the ini file. The point is in EITHER MODE a php file that starts with . > There's no reason to kill good > code that passes its tests just because it uses inline HTML. I won't > even know I have that code in my project from some third party library > until I find out the hard way. No, just no. (: I'm not trying to kill anything. In fact what I'm proposing would be a smooth transition to something that is already done. The difference is at some point you won't be able to do this: Print me! I did propose one new keyword, but by proposing one keyword with a > future-friendly syntax instead of four new keywords I'm attempting to > help with the pollution problem. It's not as much as adding a keyword as it is what keyword you're adding. I hope the way I've explained things makes sense. Luke > > On Mon, Apr 9, 2012 at 11:43 AM, Luke Scott wrote: >> Tom, >> >> As I've said before I don't think new keywords are the answer. They >> will just pollute the language even further. >> >> I also don't think an ini setting is a bad thing either. It is often >> used in PHP as a way to transition from way of doing things to >> another. First you introduce it with it being off by default, then on >> by default, then deprecate the old behavior. It's quite normal in >> PHP's history. >> >> In another email someone mentioned doing two rfcs. In both cases are >> we talking about removing > confusing to keep track of what is being talked about. If that is the >> case, continue reading. >> >> I would prefer the starting > Just explicitly forbid the ending ?> tag and treat text before the >> opening > or throw an error. >> >> That is at least how I would prefer the "code" mode as most >> non-template files only start with > compatibility. >> >> If you must add keywords it should be something like require_template >> NOT require_code/require_file. Templates are the exception, not the >> norm. >> >> Luke Scott >> >> On Apr 8, 2012, at 9:32 AM, Tom Boutell wrote: >> >>> I have written an RFC proposing backwards-compatible support for >>> source files without an opening >> >>> https://wiki.php.net/rfc/source_files_without_opening_tag >>> >>> This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure >>> what the requirements are to get it added to the "Under Discussion" >>> session and get the ball rolling formally. Please enlighten and I'll >>> do whatever is required. >>> >>> Thanks! >>> >>> -- >>> Tom Boutell >>> P'unk Avenue >>> 215 755 1330 >>> punkave.com >>> window.punkave.com >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Tom, As I've said before I don't think new keywords are the answer. They will just pollute the language even further. I also don't think an ini setting is a bad thing either. It is often used in PHP as a way to transition from way of doing things to another. First you introduce it with it being off by default, then on by default, then deprecate the old behavior. It's quite normal in PHP's history. In another email someone mentioned doing two rfcs. In both cases are we talking about removing tag and treat text before the opening wrote: > I have written an RFC proposing backwards-compatible support for > source files without an opening > https://wiki.php.net/rfc/source_files_without_opening_tag > > This RFC is not yet listed at https://wiki.php.net/rfc. I am not sure > what the requirements are to get it added to the "Under Discussion" > session and get the ball rolling formally. Please enlighten and I'll > do whatever is required. > > Thanks! > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 7, 2012, at 11:14 AM, Pierre Joye wrote: > On Sat, Apr 7, 2012 at 6:51 PM, Luke Scott wrote: > >> I think I understand what you're getting at. So to avoid fragmentation >> you would have to have two independent memory spaces. Making non >> persistent memory persistent would require copying from one space to >> another. Is that correct? > > Yes, that's correct. > >> How is this handled in other platforms where you have an application >> instance (with state, if that's the correct terminology)? > > Application server is something different. PHP is not one, as it could > be possible to do that using the builtin web server (dev only :). An application server would be cool though. I was thinking along the lines of having each process be an instance of the application.. thus the idea about persisting objects. >> Are there any other options for reliably persisting objects/variables >> (without having to recreate)? > > Something I have been discussed in the past with a couple of persons > is to have a mechanism to automatically instantiate objects on request > start. That's not persistent objects but that could already boost a > little it the base foot print of some frameworks. How would that work? I'm intrigued. Luke > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 7, 2012, at 9:45 AM, Pierre Joye wrote: > hi, > > On Sat, Apr 7, 2012 at 4:59 PM, Luke Scott wrote: > >>> The expensive parts here are not the object creation on its own but to >>> get the data they contain (external, calculation, etc.). >> >> With heavy objects, yes. But when you have hundreds of objects? The >> unseralization process in no more efficient than creating the objects >> directly. > > That's what I am saying, yes. Hence that I do not think persistent > objects are that much helpful. I guess it depends on the use case. > >> It depends. It's only cheaper when you have heavy objects. >> >> How do other platforms with a persistent application instance handle this? > > It is horrible in Java. There are some work being made in JS (server > side) too which looks good, but it is basically the same as we discuss > here. Are we talking about v8cgi or Node? Node has a single application instance, but everything has to be asynchronous... > >> I think the bigger issues are how to persist the memory without >> fragmentation. Stanislav talked about that (although those comments >> didn't make it to the list - my fault for not hitting reply all). > > Then post it again here. Done. > >>> The serialization method can be optimized easily, igbinary for example >>> can help to speed up this process. >> >> Optimized, sure. But you can only go so far. You still have the cost >> of recreating those objects. The only way to make it truly zero is by >> not recreating them. > > Right, but the gain is not worth it except in hello world example. > Well, for the large majority of the use cases. In a hello world the difference is probably not measurable. When you start to see it is with hundreds of class instances. > >> igbinary helps. But what about a large binary tree? The only way to >> efficiently keep this in memory (currently) is to write a C/C++ >> extension that persists the memory as a resource. But this takes much >> more time and effort than writing it in PHP. > > I wonder about the opportunity and design correctness to keep large > binary trees in memory, but that's maybe another discussion :) I personally don't, but it was one of the use cases I found where serialization had no benefit. > > >> With a lot of large frameworks you spend more time initializing the >> framework than the request itself (besides querying external resources >> like MySQL). > > In most if not any applications, "(besides querying external resources > like MySQL)" is what takes the largest part of the request time. > That's why I do not think persistent zval is going to bring us that > far. True, for most PHP applications today. But when you hit these limitations you often have to work outside PHP and bind that solution to it. Whereas java, as "horrible" as it is, can handle almost any situation. A classic example of something I couldn't do in PHP: Large file uploads (> 2GB). Our solution was writing an app in java, powered by jetty, to stream the file to the server. It works beautifully , but it had to be done outside PHP. > > >> I think the most frustrating thing for me is knowing this isn't an >> issue with web applications written in Java, which has an always on >> application instance that handles requests. I've always viewed java as >> bloated and slow... But with recent developments of Java being jit >> compiled to native code, these issues are starting to go away. > > It is not really what I see. Many projects I have seen have been > moving away from persistent objects across requests (for the part you > are referring to here), as it adds an insane amount of complexity that > is not worth the effort. I suppose it depends on the industry. In the credit card processing industry (gateways) I see Java a lot. I almost never see PHP in this area. Luke > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 6, 2012, at 10:41 PM, Stas Malyshev wrote: > Hi! > >> How is memory tracked with emalloc? From my observations anything >> created with emalloc, with or without a zval wrapper, is freed at the >> end of the request. Things created with pemalloc, which seems to be a >> wrapper of malloc, isn't thrown away. > > Zend Engine has its own memory manager, see zend_alloc.c. Unfortunately, > I'm not sure I'll be able to explain in short how it works, but TLDR > version of it is that it's like malloc, but private to Zend Engine, so > everything is freed at the end of the request. > >> From what I've seen this is because the zvals, the values inside, the >> object bucket, etc... is all created by emalloc. Correct me if I'm >> wrong, but even if i could persist the zval (wrapper) the value inside >> would be freed unless both the zval and the value were created with >> pemalloc (alias of malloc). It goes a step further with the objects >> because a zend_object is just a handle ID (pointing to a spot in the >> bucket) and a pointer to object handlers. > > This is correct, all internal memory allocations are done by emalloc. > zend_object, however, is not just a handle - this handle refers to > object structure, which has class pointer, properties, etc. > >> and not much better than serialization. I'd like to avoid copying >> memory if possible. A flag on the zval would be ideal. > > That's what I am trying to explain - flag on one zval would not help > you, since this zval uses dozens, if not hundreds (for bigger object) > other resources, including other zvals, hashtables, object structures, > class structures, function structures, etc. etc. > Add to that that if you allocated something in emalloc arena you can not > just mark it "do not free it" - that would create a huge fragmentation > problem if you had something non-freeable at the middle of freeable > region. So you can not just "flag" random variable as non-freeable > without messing up whole memory manager (btw, not advisable with malloc > either - fragmentation can inflate you memory usage very easily). Not > that it would work even if you could, see above. I think I understand what you're getting at. So to avoid fragmentation you would have to have two independent memory spaces. Making non persistent memory persistent would require copying from one space to another. Is that correct? How is this handled in other platforms where you have an application instance (with state, if that's the correct terminology)? Are there any other options for reliably persisting objects/variables (without having to recreate)? (Re-sending to the list) > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On Apr 7, 2012, at 9:04 AM, Tom Boutell wrote: > A thoughtful suggestion. But the trouble with a php.ini setting is that you > can't tell if it is enabled when writing your class file. That makes it > impossible to write portable libraries. The keywords would always be > available. And no one has to type them outside of an auto loader (: > > Sent from my iPhone Why would you need to? With it on or off ends php code and prints text between it and the next is explicitly forbidden. If classes start with this should be fine. Most classes written with PHP 5+ comparability do this anyway. The only way I see this not working is for PHP short tags where PHP is used as a template language. A lot of people decide to use other template engines though, like Twig. I personally avoid short tags on large projects and use them only on small quick and dirty projects. Luke (Sorry, I keep forgetting to hit reply all) > > On Apr 7, 2012, at 11:46 AM, Luke Scott wrote: > >> On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote: >> >>> That's a good point too. >>> >>> I think this is a better proposal: >>> >>> include_code, require_code, and require_code_once would work just like >>> include, require and require_once, except that the parser would start >>> out in PHP mode. >>> >>> .phpc is then just a convention for naming PHP files that start out >>> with code - a convention that autoloaders should respect, just as they >>> now respect the .php convention. "The user asked for the Monkey class, >>> and I see Monkey.phpc is out there; I'll grab that with >>> require_code_once." >>> >>> Putting this decision on the autoloader makes more sense because >>> autoloaders already contain assumptions about file extensions. They >>> have to in order to do their job of translating a class name to a >>> particular path somewhere. >>> >>> Folks who did not care for this functionality could then choose to >>> entirely ignore it. Class library developers who liked it would make >>> autoloaders available that honored it, freeing end-user developers >>> from thinking about it. It becomes self-contained, and people who are >>> writing old-school .php standalone scripts or pages are entirely >>> unaffected. >> >> Tony I think your idea has some merit. If it were up to me I'd remove >> > >> But I feel that adding new keywords is not the way to do it. >> Personally I'd like to see a php.ini setting to disallow the ending ?> >> tag and assume .php files just have PHP code. The starting > would be optional. White space would be ignored and non-white space >> characters before > >> Doing it this way would disallow bad practices but still make existing >> PHP scripts compatible. >> >> I think that doing that would be quite reasonable. Those who complain >> about it likely ignore industry best practices anyway. This option >> could be turned off by default at first, made default later, and then >> ?> be deprecated all together. >> >> So with this option enabled ?> is forbidden, > the text before > text before throws an error (unless it's a shebang line in cli mode). >> >> Hopefully that made sense. Does this sound good to you? >> >> I'm sorry you had to endure such a nasty troll. I am so sick of self >> righteous bullies who think they know it all. >> >> Luke >> >>> >>> On Sat, Apr 7, 2012 at 9:50 AM, John Bafford wrote: >>>> >>>> On Apr 7, 2012, at 09:39, Tom Boutell wrote: >>>> >>>>>> From the viewpoint of someone writing reusable classes, the need to >>>>> start with >>>> above it is a silly annoyance they don't experience with other tools. >>>>> >>>>> That said, you are making valid points, I'm not convinced myself that >>>>> "file extensions" necessarily should or could be determined in every >>>>> context. But it seems the most viable way of addressing the issue - if >>>>> a viable way even exists. Partly I want to convince myself that this >>>>> either can or can't ever be improved, and move on either way (: >>>> >>>> That "silly annoyance" doesn't seem to bother anyone who writes command >>>> line tools, which require the #! line specifying the command interpreter >>>> to be the first bytes in the file, with no leading white space whatsoever. >>>> Especially on unix systems (but a
Re: [PHP-DEV] PHP class files without
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote: > That's a good point too. > > I think this is a better proposal: > > ... Tom, sorry! For some reason I thought Tony :). On my phone... Not as intuitive as my desktop... Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP class files without
On Apr 7, 2012, at 7:00 AM, Tom Boutell wrote: > That's a good point too. > > I think this is a better proposal: > > include_code, require_code, and require_code_once would work just like > include, require and require_once, except that the parser would start > out in PHP mode. > > .phpc is then just a convention for naming PHP files that start out > with code - a convention that autoloaders should respect, just as they > now respect the .php convention. "The user asked for the Monkey class, > and I see Monkey.phpc is out there; I'll grab that with > require_code_once." > > Putting this decision on the autoloader makes more sense because > autoloaders already contain assumptions about file extensions. They > have to in order to do their job of translating a class name to a > particular path somewhere. > > Folks who did not care for this functionality could then choose to > entirely ignore it. Class library developers who liked it would make > autoloaders available that honored it, freeing end-user developers > from thinking about it. It becomes self-contained, and people who are > writing old-school .php standalone scripts or pages are entirely > unaffected. Tony I think your idea has some merit. If it were up to me I'd remove tag and assume .php files just have PHP code. The starting be deprecated all together. So with this option enabled ?> is forbidden, > On Sat, Apr 7, 2012 at 9:50 AM, John Bafford wrote: >> >> On Apr 7, 2012, at 09:39, Tom Boutell wrote: >> From the viewpoint of someone writing reusable classes, the need to >>> start with >> above it is a silly annoyance they don't experience with other tools. >>> >>> That said, you are making valid points, I'm not convinced myself that >>> "file extensions" necessarily should or could be determined in every >>> context. But it seems the most viable way of addressing the issue - if >>> a viable way even exists. Partly I want to convince myself that this >>> either can or can't ever be improved, and move on either way (: >> >> That "silly annoyance" doesn't seem to bother anyone who writes command line >> tools, which require the #! line specifying the command interpreter to be >> the first bytes in the file, with no leading white space whatsoever. >> Especially on unix systems (but also on the Mac), the file extension does >> not affirmatively indicate the file type or whether or not it can be >> executed. >> >> Also, from a CLI perspective, you don't want extensions in the names of your >> scripts, because then it causes problems/confusion/extra work if you later >> decide to change the language the script is written in. >> >> -John >> >> -- >> John Bafford >> http://bafford.com/ >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 7, 2012, at 5:22 AM, Pierre Joye wrote: > hi, > > 2012/4/7 Luke Scott : > >> It would be ideal of you could initialize a bunch of objects once and >> carry them over to the next request. No serialization, no copying. A >> lot of framework objects would benefit from this. > > The expensive parts here are not the object creation on its own but to > get the data they contain (external, calculation, etc.). With heavy objects, yes. But when you have hundreds of objects? The unseralization process in no more efficient than creating the objects directly. > That's why we have magic methods like __sleep and __wakeup. Making > objects or values persistent across requests is not possible or very > hard. It is way cleaner to create them on each request and save the > expensive computation or data fetching time (see doctrine for example) > instead of trying to figure out tricks to get rid of the references > and all other ways to mess up a zval between requests. It depends. It's only cheaper when you have heavy objects. How do other platforms with a persistent application instance handle this? I don't believe references are really that big of an issue. You still have scope and refcounts. The difference is now refcounts are ignored and everything is thrown away at the end of the request vs refcounts being observed and memory persisting past the request. I think the bigger issues are how to persist the memory without fragmentation. Stanislav talked about that (although those comments didn't make it to the list - my fault for not hitting reply all). > The serialization method can be optimized easily, igbinary for example > can help to speed up this process. Optimized, sure. But you can only go so far. You still have the cost of recreating those objects. The only way to make it truly zero is by not recreating them. igbinary helps. But what about a large binary tree? The only way to efficiently keep this in memory (currently) is to write a C/C++ extension that persists the memory as a resource. But this takes much more time and effort than writing it in PHP. > It is also important to keep in mind that PHP is not designed to have > persitant user land values and won't be. > There are very good tools to > store these data, like memcached, couchbase, redis and co for the > distributed ones, apc and other for local caches (even like mysqlnd_cc > for caching mysql results :). And these are great solutions to a different set of problems. But they aren't the token solution to every problem. With a lot of large frameworks you spend more time initializing the framework than the request itself (besides querying external resources like MySQL). I think the most frustrating thing for me is knowing this isn't an issue with web applications written in Java, which has an always on application instance that handles requests. I've always viewed java as bloated and slow... But with recent developments of Java being jit compiled to native code, these issues are starting to go away. I have invested 10 years into PHP. Id rather stick with what I know. But it scares me that many enterprises in our sector chose Java over PHP. Luke > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 6, 2012, at 5:23 PM, "Johannes Schlüter" wrote: > Hi, > > On Fri, 2012-04-06 at 16:46 -0700, Luke Scott wrote: >> >> >> From what I've gathered thus far, it is impossible to do without >> copying the non-persistent memory into persistent memory, and then >> back again. I'm assuming this is because all the memory associated >> with PHP variables use emalloc, which places it onto a stack that is >> disposed of at the end of the request. >> >> So there seems to only be two ways to do this: >> >> 1 - Copy non-persistent memory into persistent memory (and back) using >> a deep copy. Probably not very efficient. May not be much better than >> serialization. > > Yes, see apc_store() and friends to see all the small parts needed to > copy it as properly as possible. While this still won't work for all > cases (resources, internal classes, ..) but well, this might be what > you're looking for in a ready state ;-) Apc serializes the data. Unless the data is a cache or session information there is almost no difference between unseralizing a bunch of objects verses and initializing the objects in code. It would be ideal of you could initialize a bunch of objects once and carry them over to the next request. No serialization, no copying. A lot of framework objects would benefit from this. > >> 2 - Modify the Zend engine to flag objects/zvals as persistent so they >> aren¹t thrown away until the process ends. > > Which is a major undertaking, taking copy-on-write and friends into > account. As in a case like > >mark_persistent($persistent); >$persistent['some key'] = function_returning_lots_of_data(); > > would suddenly require to create a copy of all the data. Such things can > quickly cost more than recreating the structures more frequently ... When having to copy data, yes thing yet messy very quickly. But if there were a persistent flag on the zval the new zval would have the persistent flag. The old one would be discarded when it's reference count reached zero. Right now everything is thrown out at the end of the request because it's created with emalloc, regardless of the recount. With a persistent flag (1 or 0) and a recount of 1 or greater it wouldn't be until the end of the process. Easier said than done - for sure. > > johannes > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Persistent zvals
On Apr 6, 2012, at 5:16 PM, Stas Malyshev wrote: Hi! >From what I've gathered thus far, it is impossible to do without copying the non-persistent memory into persistent memory, and then back again. I'm assuming this is because all the memory associated with PHP variables use emalloc, which places it onto a stack that is disposed of at the end of the request. The stack part is wrong, emalloc does not use stack, but the general sense of it is correct - all memory allocated by emalloc is freed at the end of the request, so anything you would want to preserve would have to be copied to some other memory area. How is memory tracked with emalloc? From my observations anything created with emalloc, with or without a zval wrapper, is freed at the end of the request. Things created with pemalloc, which seems to be a wrapper of malloc, isn't thrown away. I saw some references (off the top if my head - on my phone) to something like G(mm_stack)->_malloc(...), which is called by emalloc. Could you briefly explain how it does work or point be to a link that does? Up until now I've been pouring over the source code - and there is a lot, tracing down macro after macro. 2 - Modify the Zend engine to flag objects/zvals as persistent so they aren¹t thrown away until the process ends. The problem with that is that these variables can contain references to other variables and other things (like class in object, etc.) that will be freed, so the data will point to freed memory. Unless the variable is a simple scalar or you do not allow associating it with any other variables in any way you would have this problem. If it's a simple scalar, you can do better by using existing caches. Not allowing associations with other variables means there's not much reason for this thing to actually be a PHP variable. >From what I've seen this is because the zvals, the values inside, the object bucket, etc... is all created by emalloc. Correct me if I'm wrong, but even if i could persist the zval (wrapper) the value inside would be freed unless both the zval and the value were created with pemalloc (alias of malloc). It goes a step further with the objects because a zend_object is just a handle ID (pointing to a spot in the bucket) and a pointer to object handlers. I've been able to do it somewhat with string zvals, but objects are a different story (given that a zval contains a handle index referring an entry in a bucket). The "goal", at least with objects, is the objects doesn't destruct until the end of the process. With copying memory it looks With objects you have a problem - do you also mean to keep the class? What about the methods code? If you intend to keep all this in memory - and remember you'd also have to guard all of it so no "local" variable gets anywhere into any of object's properties, or sub-values of these properties - I'm not sure you'd do better than serializing. At this point I feel light a mad scientist. I'm hoping to gain some insight on how this might be done properly with PHP 5.3/5.4 (or just 5.4) - even if it involves modifying the Zend engine. Have you guys had any recent discussions about doing this? Doing it is much harder than you think, since all structures in Zend Engine are assumed to be temporary and you'd need to copy a lot of stuff to make your object work. I wouldn't really advise it. Don't get me wrong - I totally get it. Trying to copy the zvals, the value inside, and the object out of the bucket, and then the descendants is not a good solution. It would probably be buggy at best and not much better than serialization. I'd like to avoid copying memory if possible. A flag on the zval would be ideal. With the continued assumption that memory structures are temporary something like this will never be feasible. In order for something like this to work (at least from my understanding. - I'm probably totally wrong) values inside a zval would have to be created with malloc and the life cycle of that object would have to be determined by the wrapping zval. A zval would have a persistent flag and a recount the value inside would be released when the recount reaches zero or at the end of the request if the persistent flag is zero But this is something totally different than it is now. Luke -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227
[PHP-DEV] Persistent zvals
I've spent the last few days pouring over the Zend engine source code. I think I have a basic understanding on the memory management. Likely what I say may be incorrect, so I apologize in advance. What I'm trying to do is write an extension to persist PHP variables past the end of the request in the SAPI to be used on the next request (different user, same process). I'd like to do this without serialization. The reason is certain objects in PHP (in a framework, for example) are not request specific and it would be useful to have these objects already loaded and usable without having to construct them on every request. (Sample use case: Dependency injection like Guice without having to write physical containers - using reflection, written in PHP) >From what I've gathered thus far, it is impossible to do without copying the non-persistent memory into persistent memory, and then back again. I'm assuming this is because all the memory associated with PHP variables use emalloc, which places it onto a stack that is disposed of at the end of the request. So there seems to only be two ways to do this: 1 - Copy non-persistent memory into persistent memory (and back) using a deep copy. Probably not very efficient. May not be much better than serialization. 2 - Modify the Zend engine to flag objects/zvals as persistent so they aren¹t thrown away until the process ends. #2 seems to be the better way to go. #1 seems to be the only way to do it as an extension (maintaining its own stack). There seems to have been some discussion (7 years ago) of this mentioned here under 6.9: http://www.php.net/~derick/meeting-notes.html I've been able to do it somewhat with string zvals, but objects are a different story (given that a zval contains a handle index referring an entry in a bucket). The "goal", at least with objects, is the objects doesn't destruct until the end of the process. With copying memory it looks like I'd probably have to copy the object into my own bucket, modify the original in zend's bucket so the destructor isn't called (destructor_callled = 1), and then at the start of the request copy what's in my bucket into zend's bucket. At this point I feel light a mad scientist. I'm hoping to gain some insight on how this might be done properly with PHP 5.3/5.4 (or just 5.4) - even if it involves modifying the Zend engine. Have you guys had any recent discussions about doing this? Luke
