Re: [PHP-DEV] PHP CLI setting cooked terminal mode
I've seen something similar on Debian; it might be a patch that
your distro is shipping on top of PHP.
Edward
Excerpts from Alain Williams's message of Sat Sep 14 04:45:41 -0700 2013:
Hi,
I am running a PHP script at the command line and piping the output through
less:
./myScript | less
Since less is an interactive program it puts the terminal into 'raw' mode so
that it can read characters one at a time. However, when I do the above I find
that the commands that I type to less are echoed back to me and not acted on
until I type RETURN. This is not as it should be.
The sript is not doing anything clever, just generating 100 lines:
for($i = 0; $i 100; $i++)
echo i=$i\n;
If I run the script under strace I see:
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...})
= 0
What is happening is that PHP is putting the terminal into cooked mode.
I can get it to not do this by connecting stdin to /dev/null:
./myScript /dev/null | less
another way of getting it to work is (and this shows that it really is PHP
that
is messing the tty modes):
./myScript /dev/null | (sleep 10; less)
However: PHP should not set the terminal to cooked mode in the first place.
Is there any way in which I can get PHP to not do this ?
TIA
I am running PHP 5.3.3 on CentOS 6.
I posted this to php-gene...@lists.php.net a few days ago, but did not get a
sensible reply.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Enable extension loading from .user.ini when run as CGI.
Excerpts from Pierre Joye's message of Sat Jul 28 02:20:51 -0400 2012: Functionality is not included for other SAPIs because they either do not support .user.ini (e.g. CLI) or they serve multiple requests and thus do not support dl() (e.g. FastCGI). dl has been disabled in FastCGI and other web SAPIs for a reason, it is not working well and brings php to instability. I do not think adding this to .user.ini will be any better. It has been a while, but last winter we discussed this patch and decided that extension loading was OK for short-lived PHP processes, e.g. CGI. So this patch only enables it for CGI. Can you create a patch only for this bug fix please? Ideally a bug report + patch or pull request :-) Sure, I can split in two. Does PHP use pull requests? Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Enable extension loading from .user.ini when run as CGI.
From: Edward Z. Yang ezy...@mit.edu Functionality is not included for other SAPIs because they either do not support .user.ini (e.g. CLI) or they serve multiple requests and thus do not support dl() (e.g. FastCGI). There is also a bugfix to invoke zlist_clean, to ensure extension_lists can be reused for the second round of extension appliations (since the head and tail pointers have garbage in them). Signed-off-by: Edward Z. Yang ezy...@mit.edu --- main/php_ini.c | 4 ++-- sapi/cgi/cgi_main.c | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/main/php_ini.c b/main/php_ini.c index 89a3d7e..1fde28e 100644 --- a/main/php_ini.c +++ b/main/php_ini.c @@ -709,8 +709,8 @@ void php_ini_register_extensions(TSRMLS_D) zend_llist_apply(extension_lists.engine, php_load_zend_extension_cb TSRMLS_CC); zend_llist_apply(extension_lists.functions, php_load_php_extension_cb TSRMLS_CC); - zend_llist_destroy(extension_lists.engine); - zend_llist_destroy(extension_lists.functions); + zend_llist_clean(extension_lists.engine); + zend_llist_clean(extension_lists.functions); } /* }}} */ diff --git a/sapi/cgi/cgi_main.c b/sapi/cgi/cgi_main.c index 7856e0c..d944f3a 100644 --- a/sapi/cgi/cgi_main.c +++ b/sapi/cgi/cgi_main.c @@ -818,6 +818,7 @@ static void php_cgi_ini_activate_user_config(char *path, int path_len, const cha /* Activate ini entries with values from the user config hash */ php_ini_activate_config(entry-user_config, PHP_INI_PERDIR, PHP_INI_STAGE_HTACCESS TSRMLS_CC); + php_ini_register_extensions(TSRMLS_CC); } /* }}} */ -- 1.7.11.3 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 48417 and PHP 5.4
Hey Pierre, I was wondering if you'd be willing to pitch a rollback of r300894 post-code-freeze. If not, I'll start writing error detection code to accomodate for PHP 5.4 :^) Thanks, Edward Excerpts from Edward Z. Yang's message of Sun Jan 08 11:41:50 -0500 2012: Hello Pierre, The whole situation is a slightly complicated. One question to ask is: Is there code in PHP 5.3 that worked, which now no longer works in PHP 5.4? The answer to this question is *yes*, as seen by this example: var_dump(iconv(UTF-8, ISO-8859-1//IGNORE, \xE4\xB8\xAD)); Now, the reason why this worked in PHP 5.3 was because of a bug, namely #52211, so the situation in PHP 5.3 was two wrongs make a right (except, of course, in the case where more than 8000 bytes are involved.) Fixing one of the bugs causes //IGNORE to stop working entirely. So if you ask another question, Are there less bugs in PHP 5.4 than in PHP 5.3, the answer is also yes. Now, consider the perspective of a library developer using iconv //IGNORE. In PHP 5.3, effective workarounds exist: I can fix #52211 by checking for captured errors and returning false instead, I can fix #48147 by splitting my input into 8kb chunks (mumble utf-8 boundaries) and feeding it to iconv individually. In PHP 5.4, I am left with no such redress. Because iconv will now always return false upon an input, regardless of whether or not //IGNORE is set, I can no longer do conversions with invalid inputs. It's worth repeating: #48147 is no longer iconv with //IGNORE cuts string, it's iconv with //IGNORE doesn't work. At all. I *guarantee* you large amounts of PHP code will be affected. It seems it would be better to wait for a complete fix, than to fix it partially and leave some (widely used) functionality completely broken. Is this a bug in glibc? I sincerely hope I can convince Ulrich Drepper so, since I agree that his API is completely off the wall: http://sources.redhat.com/bugzilla/show_bug.cgi?id=13541 But as it stands, Ulrich does not seem to believe that there is any bug (see that he's closed both of my upstream bugs; and, since //IGNORE is wholly undocumented, there is not really any spec I can hold him to), so it would seem most advisable for PHP to play nice, since most users are not in the position to patch their glibc installation. Cheers, Edward Excerpts from Pierre Joye's message of Sun Jan 08 07:36:03 -0500 2012: hi, I closed one bug (unrelated to what you have) and added a comment to the /ignore issue. I do not see a bug in PHP but if you have any info that shows that PHP causes this problem, then please add them to the bug so we can fix it, if not I will bogus it as there is no bug in php but in iconv (glibc or other implementations). On Thu, Jan 5, 2012 at 7:42 PM, Edward Z. Yang ezy...@php.net wrote: Hello all, I know it seems like there always is infinite pile of work to do before the PHP 5.4 release comes out, but I think this bug is worth looking at. https://bugs.php.net/bug.php?id=52211 I suggest reverting r300894, since this causes //IGNORE to stop working. Preserving functionality should probably be more important. The underlying cause of this bug is this one: https://bugs.php.net/bug.php?id=48147 But I don't think this feature is going to get implemented in time. Edward -- 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] Bug 48417 and PHP 5.4
Hello Pierre, The whole situation is a slightly complicated. One question to ask is: Is there code in PHP 5.3 that worked, which now no longer works in PHP 5.4? The answer to this question is *yes*, as seen by this example: var_dump(iconv(UTF-8, ISO-8859-1//IGNORE, \xE4\xB8\xAD)); Now, the reason why this worked in PHP 5.3 was because of a bug, namely #52211, so the situation in PHP 5.3 was two wrongs make a right (except, of course, in the case where more than 8000 bytes are involved.) Fixing one of the bugs causes //IGNORE to stop working entirely. So if you ask another question, Are there less bugs in PHP 5.4 than in PHP 5.3, the answer is also yes. Now, consider the perspective of a library developer using iconv //IGNORE. In PHP 5.3, effective workarounds exist: I can fix #52211 by checking for captured errors and returning false instead, I can fix #48147 by splitting my input into 8kb chunks (mumble utf-8 boundaries) and feeding it to iconv individually. In PHP 5.4, I am left with no such redress. Because iconv will now always return false upon an input, regardless of whether or not //IGNORE is set, I can no longer do conversions with invalid inputs. It's worth repeating: #48147 is no longer iconv with //IGNORE cuts string, it's iconv with //IGNORE doesn't work. At all. I *guarantee* you large amounts of PHP code will be affected. It seems it would be better to wait for a complete fix, than to fix it partially and leave some (widely used) functionality completely broken. Is this a bug in glibc? I sincerely hope I can convince Ulrich Drepper so, since I agree that his API is completely off the wall: http://sources.redhat.com/bugzilla/show_bug.cgi?id=13541 But as it stands, Ulrich does not seem to believe that there is any bug (see that he's closed both of my upstream bugs; and, since //IGNORE is wholly undocumented, there is not really any spec I can hold him to), so it would seem most advisable for PHP to play nice, since most users are not in the position to patch their glibc installation. Cheers, Edward Excerpts from Pierre Joye's message of Sun Jan 08 07:36:03 -0500 2012: hi, I closed one bug (unrelated to what you have) and added a comment to the /ignore issue. I do not see a bug in PHP but if you have any info that shows that PHP causes this problem, then please add them to the bug so we can fix it, if not I will bogus it as there is no bug in php but in iconv (glibc or other implementations). On Thu, Jan 5, 2012 at 7:42 PM, Edward Z. Yang ezy...@php.net wrote: Hello all, I know it seems like there always is infinite pile of work to do before the PHP 5.4 release comes out, but I think this bug is worth looking at. https://bugs.php.net/bug.php?id=52211 I suggest reverting r300894, since this causes //IGNORE to stop working. Preserving functionality should probably be more important. The underlying cause of this bug is this one: https://bugs.php.net/bug.php?id=48147 But I don't think this feature is going to get implemented in time. Edward -- 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
[PHP-DEV] Bug 48417 and PHP 5.4
Hello all, I know it seems like there always is infinite pile of work to do before the PHP 5.4 release comes out, but I think this bug is worth looking at. https://bugs.php.net/bug.php?id=52211 I suggest reverting r300894, since this causes //IGNORE to stop working. Preserving functionality should probably be more important. The underlying cause of this bug is this one: https://bugs.php.net/bug.php?id=48147 But I don't think this feature is going to get implemented in time. Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Load extensions for .user.ini files
Excerpts from Hannes Magnusson's message of Fri Nov 11 18:54:27 -0500 2011: Hmh. Whats the difference between .user.ini and -dextension=? I hate it when bucketloads of .ini files are picked up when I run PHP via cli The idea would be to make it easy to simulate the same configuration as when you run from the web as when you run from the command line, since scripts might be sensitive to those parameters. Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Load extensions for .user.ini files
Well, I'm kind of hoping this patch will go in, so we don't have to bother with a bug. I can if you really want me to. Cheers, Edward Excerpts from Christopher Jones's message of Fri Nov 11 14:28:30 -0500 2011: On 11/10/2011 07:14 PM, Edward Z. Yang wrote: The change to zlist_clean is necessary because otherwise extension_lists can't be reused for the second round of extension appliations (since the head and tail pointers have garbage in them). You should probably take that fix regardless of what you think of the feature change. What about logging a bug for that specific change so it doesn't get lost, and so it can be tracked? Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Load extensions for .user.ini files
http://svn.php.net/repository/php/php-src/branches/PHP_5_3 r318957 We also applied it to 5.3.8 release, although we had to fix up the patch for that. I can port it to 5.4. Edward Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011: Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk It is short and simple so I could do it manually, of course, but I'd like to know what you have been testing it against. On 11/10/2011 07:14 PM, Edward Z. Yang wrote: Here is the proposed patch (sans tests; we did our own manual testing on 32-bit and 64-bit, and had to fix an unrelated bug; will provide tests when you say so): http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch The change to zlist_clean is necessary because otherwise extension_lists can't be reused for the second round of extension appliations (since the head and tail pointers have garbage in them). You should probably take that fix regardless of what you think of the feature change. Edward Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: On 11/08/2011 12:23 AM, Edward Z. Yang wrote: Hello all, My team is interested in permitting .user.ini files to load extensions. We believe this to be a simple fix: add an invocation of php_ini_register_extensions to the end of sapi/cgi/cgi-main.c. I don't believe this steps on any invariants, since extensions can usually be loaded arbitrarily late. Let me know what the list thinks. I can submit a patch and tests if y'all decide it's a good idea. You are aware that these extensions can't be unloaded, right? So one user loading an extension will potentially be stepping on another user and breaking their code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Load extensions for .user.ini files
Excerpts from Rasmus Lerdorf's message of Fri Nov 11 15:45:27 -0500 2011: Well, it is simple enough that we don't really need a patch. However, generally if you want to submit a patch it needs to be against a current svn branch and not an old release. You want to minimize the work people will need to do to look at your suggested change. Gotcha. The other issue with your patch is that you are enabling this for the fpm sapi. I thought we agreed that this should only be in the sapis that supported dl() and those are cgi, cli and embed. And .user.ini doesn't apply to embed, so it would just be cli and cgi because these are the non-persistent cases where there is no danger of screwing up the next request with a bad extension in a .user.ini file. Hmm, it looks like cli doesn't have .user.ini support at all. Does this mean we should implement .user.ini for these SAPIs? I'd be in favor. Edward -Rasmus On 11/11/2011 11:42 AM, Edward Z. Yang wrote: http://svn.php.net/repository/php/php-src/branches/PHP_5_3 r318957 We also applied it to 5.3.8 release, although we had to fix up the patch for that. I can port it to 5.4. Edward Excerpts from Rasmus Lerdorf's message of Fri Nov 11 14:38:13 -0500 2011: Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk It is short and simple so I could do it manually, of course, but I'd like to know what you have been testing it against. On 11/10/2011 07:14 PM, Edward Z. Yang wrote: Here is the proposed patch (sans tests; we did our own manual testing on 32-bit and 64-bit, and had to fix an unrelated bug; will provide tests when you say so): http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch The change to zlist_clean is necessary because otherwise extension_lists can't be reused for the second round of extension appliations (since the head and tail pointers have garbage in them). You should probably take that fix regardless of what you think of the feature change. Edward Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: On 11/08/2011 12:23 AM, Edward Z. Yang wrote: Hello all, My team is interested in permitting .user.ini files to load extensions. We believe this to be a simple fix: add an invocation of php_ini_register_extensions to the end of sapi/cgi/cgi-main.c. I don't believe this steps on any invariants, since extensions can usually be loaded arbitrarily late. Let me know what the list thinks. I can submit a patch and tests if y'all decide it's a good idea. You are aware that these extensions can't be unloaded, right? So one user loading an extension will potentially be stepping on another user and breaking their code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Load extensions for .user.ini files
Here is the proposed patch (sans tests; we did our own manual testing on 32-bit and 64-bit, and had to fix an unrelated bug; will provide tests when you say so): http://web.mit.edu/~ezyang/Public/php-user-ini-extension.patch The change to zlist_clean is necessary because otherwise extension_lists can't be reused for the second round of extension appliations (since the head and tail pointers have garbage in them). You should probably take that fix regardless of what you think of the feature change. Edward Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: On 11/08/2011 12:23 AM, Edward Z. Yang wrote: Hello all, My team is interested in permitting .user.ini files to load extensions. We believe this to be a simple fix: add an invocation of php_ini_register_extensions to the end of sapi/cgi/cgi-main.c. I don't believe this steps on any invariants, since extensions can usually be loaded arbitrarily late. Let me know what the list thinks. I can submit a patch and tests if y'all decide it's a good idea. You are aware that these extensions can't be unloaded, right? So one user loading an extension will potentially be stepping on another user and breaking their code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Load extensions for .user.ini files
Hello all, My team is interested in permitting .user.ini files to load extensions. We believe this to be a simple fix: add an invocation of php_ini_register_extensions to the end of sapi/cgi/cgi-main.c. I don't believe this steps on any invariants, since extensions can usually be loaded arbitrarily late. Let me know what the list thinks. I can submit a patch and tests if y'all decide it's a good idea. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Load extensions for .user.ini files
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: You are aware that these extensions can't be unloaded, right? So one user loading an extension will potentially be stepping on another user and breaking their code. Yep. If you like, I can make it so that it only applies for CGI requests, not FastCGI requests. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Load extensions for .user.ini files
Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:54:56 -0500 2011: It should match the dl() SAPI availability. OK, can do! Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Autoloader invariant
Hello all, long time no see. When I am inside the body of an autoloader function, am I allowed to assume the invariant that the class passed to the autoloader function does not exist? Last time I checked, PHP was still single-threaded, so this invariant being broken would be quite suprising to me, but a user reports that they are seeing precisely this behavior from a combination of Zend Debugger + APC. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug tracker cannot connect to database
I don't know if this is the right list to report to, but bugs.php.net is currently non-functional. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Per-directory PHP configuration
Hello all, I cooked up a patch that gives PHP support for per-directory php.ini files that properly inherit. This makes php.ini files act a little like .htaccess files. We are cognizant of the associated performance issues, and thus this is a strictly optional feature. For a little history, the current, common approach is to set PHPRC to be the current directory, so that a php.ini file from that directory is read. This unfortunately also overloads the global php.ini file, has an odd ordering with respect to php.d, and means that you have to place a php.ini file/symlink in every directory where PHP scripts could be run. While the patch is no where near where I would be comfortable formally submitting it for review on internals, I'd like to gauge how friendly the core PHP developers would be to an enhancement like this. In a nutshell, here is how the patch works: In php_ini.c, php_init_config() is patched to call php_user_init_config() if user directory php.ini's are accepted. The function then: 1. Retrieves the current working directory 2. Checks if the cwd is inside the user's home directory 3. Successively walks up from the user's home directory to the cwd, checking if a php.ini exists and loading it with zend_parse_ini_file if it does. We also have two special cases of behavior that we found helpful for our use-case: * We serve only a user's ~/web_scripts directory, so perform an optional check to make sure the PHP file is in the right place, and to not attempt to load ~/php.ini * If we had Apache frob $HOME such that it points to a different home directory, which is the web serve directory, skip the previous check. To get an idea for its behaviors, take the following example: /etc/php.ini foo = 1 bar = 1 /mit/user/web_scripts/wiki/php.ini foo = 2 Then, we see the following behavior for the following PHP scripts /mit/user/web_scripts/test.php foo = 1 bar = 1 /mit/user/web_scripts/wiki/test.php foo = 2 bar = 1 /mit/user/web_scripts/wiki/subdir/test.php foo = 2 bar = 1 I am looking forward to your comments, and I can post the very rough (but functional) patch if you are so interested. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Per-directory PHP configuration
Excerpts from Pierre Joye's message of Mon Aug 24 18:03:14 -0400 2009: The patch is missing. I intentionally omitted it, since it had some code specific to our environment. I have posted it here: http://web.mit.edu/~ezyang/Public/php-scripts.patch It is very very rough and does things that would never ever be allowed in the PHP core. However I already have a question. I hope you know that we introduced the ini per dir in 5.3. It supports user ini files in the document root, [PATH=...] in the main php.ini, etc. Did you improve it or started from scratch? The patch is off of PHP 5.2 (which we have deployed); I wasn't aware until recently of the new ini per dir functionality. I don't think it has quite the same functionality though. Btw, for previous php versions, did you look at pecl's htscanner as well? I had not heard of htscanner, and on the prompting of your mail went and looked it up. That is a very interesting implementation, although due to backwards-compatibility we can't exactly tell all of our users to convert their php.ini files into htaccess files ;-) If I have misinterpreted, please let me know (I only made cursory glances through the associated diffs/source code). Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Per-directory PHP configuration
Excerpts from Pierre Joye's message of Mon Aug 24 18:21:32 -0400 2009: Please point out the differences and list what else you may need. I do not think we will introduce another feature but improve the current implementation. As I understand it, the features are not compatible. One takes an explicit list of directories to scan, while the other dynamically determines it based on the current working directory and the user's home directory. (There are some other features on top of this, but that's the essential functionality). Please let me know if I am mistaken. It is easy to make htscanner support ini format instead :) That is true. However, it would be nice to see this go into the core, so as to encourage wide use (also, htscanner is something of a hack, quite frankly.) Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Per-directory PHP configuration
Excerpts from Pierre Joye's message of Mon Aug 24 19:37:38 -0400 2009: - It looks in the current directory for ini file (named by default .user.ini) and scan the parent directories up to the document root to apply rules from other .user.ini. My apologies, I was reading php_ini.c and didn't realize the appropriate logic was in a different file. Now having read php_cgi_ini_activate_user_config() I believe that the new functionality perfectly fits our use case. Thanks, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI and opcode caches
Excerpts from Peter Wang's message of Mon Jul 13 05:34:33 -0400 2009: http://www.php.net/manual/en/apc.configuration.php#ini.apc.enable-cli is that what you want? Not really, since the manual even specifically states that the opcode cache will get created and destroyed. I think Thomas is looking for something a little similar to Python's pyc files. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't use embeded sapi
Excerpts from Thomas Koch's message of Mon Jul 13 16:15:10 -0400 2009: worker.o: In function `main': /var/checkouts/gearman-php-worker/worker.c:5: undefined reference to `php_embed_init' /var/checkouts/gearman-php-worker/worker.c:6: undefined reference to `php_embed_shutdown' collect2: ld returned 1 exit status My guess is that you're missing some includes that you may need. Double check your code against that in the book. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git mirror of svn.php.net
Excerpts from David Soria Parra's message of Mon Jul 13 15:38:04 -0400 2009: Quite a few people mentioned that they want to use git as a frontend to the svn server. Therefore most of them need an initial import of the svn.php.net repository using git-svn. As this operation will retrieve every version in the repository, we decided to offer a semi-official git mirror. Awesome! Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] constructors are callable as regular functions.
Excerpts from troels knak-nielsen's message of Thu Jul 02 10:55:48 -0400 2009:
I understand that. It's not a technical issue - It's more a matter of
language semantics. Constructors are used for initializing state on an
object. Basically, this behaviour makes it impossible to implement
immutable objects in php. It's not a huge deal - I don't remember ever
seen __construct() called directly.
Au contraire, you can employ this little trick:
class A {
private $a;
private function __construct($a) {
$this-a = a;
}
public function make($a) {
return new A($a);
}
}
But I agree; stab anyone who is doing $foo-__construct(). Except for
testing. Testing is ok.
Cheers,
Edward
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0 Released!
Excerpts from Lukas Kahwe Smith's message of Tue Jun 30 09:01:16 -0400 2009: The PHP Development Team would like to announce the immediate release of PHP 5.3.0. This release is a major improvement in the 5.X series, which includes a large number of new features and bug fixes. Congratulations on the release. It's been a long road to PHP 5.3, and even longer until its ubiquity, but for those early adopters these new language features are much appreciated. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] add scream feature to core
So, my understanding of the shut-up operator was that it temporarily set error_reporting to zero, so you could define a custom error handler that would do the equivalent simply by not honoring error_reporting = 0. Something that would be more useful, and that I don't think is implementable in PHP, would be a wrapper around all user error handlers, since userland code can override the current error handler. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Don't compress empty output with zlib
CC'ed authors of zlib.c
Could this patch be applied to PHP_5_2 and further?
Index: ext/zlib/zlib.c
===
RCS file: /repository/php-src/ext/zlib/zlib.c,v
retrieving revision 1.183.2.6.2.8
diff -u -r1.183.2.6.2.8 zlib.c
--- ext/zlib/zlib.c 31 Dec 2008 11:17:47 - 1.183.2.6.2.8
+++ ext/zlib/zlib.c 17 Feb 2009 22:13:40 -
@@ -979,7 +979,7 @@
{
zend_bool do_start, do_end;
- if (!ZLIBG(output_compression)) {
+ if (!ZLIBG(output_compression) || SG(sapi_headers).http_response_code
== 304) {
*handled_output = NULL;
} else {
do_start = (mode PHP_OUTPUT_HANDLER_START ? 1 : 0);
Cheers,
Edward
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Don't compress empty output with zlib
Edward Z. Yang wrote: The previous patch is wrong (it doesn't handle the flush();flush(); case well). Here's a better one, although it's 304 specific: Bump? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Don't compress empty output with zlib
Hello all, I've cooked up a short patch for Bug 42362, and would
appreciate comments. The patch turns off zlib compression if there is no
output, to make zlib_compression play more nicely with 304s.
Cheers,
Edward
Index: ext/zlib/zlib.c
===
RCS file: /repository/php-src/ext/zlib/zlib.c,v
retrieving revision 1.183.2.6.2.8
diff -u -r1.183.2.6.2.8 zlib.c
--- ext/zlib/zlib.c 31 Dec 2008 11:17:47 - 1.183.2.6.2.8
+++ ext/zlib/zlib.c 17 Feb 2009 20:43:28 -
@@ -979,7 +979,7 @@
{
zend_bool do_start, do_end;
- if (!ZLIBG(output_compression)) {
+ if (!ZLIBG(output_compression) || !output_len) {
*handled_output = NULL;
} else {
do_start = (mode PHP_OUTPUT_HANDLER_START ? 1 : 0);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Don't compress empty output with zlib
Edward Z. Yang wrote:
Hello all, I've cooked up a short paonetch for Bug 42362, and would
appreciate comments. The patch turns off zlib compression if there is no
output, to make zlib_compression play more nicely with 304s.
The previous patch is wrong (it doesn't handle the flush();flush(); case
well). Here's a better one, although it's 304 specific:
Index: ext/zlib/zlib.c
===
RCS file: /repository/php-src/ext/zlib/zlib.c,v
retrieving revision 1.183.2.6.2.8
diff -u -r1.183.2.6.2.8 zlib.c
--- ext/zlib/zlib.c 31 Dec 2008 11:17:47 - 1.183.2.6.2.8
+++ ext/zlib/zlib.c 17 Feb 2009 22:13:40 -
@@ -979,7 +979,7 @@
{
zend_bool do_start, do_end;
- if (!ZLIBG(output_compression)) {
+ if (!ZLIBG(output_compression) || SG(sapi_headers).http_response_code
== 304) {
*handled_output = NULL;
} else {
do_start = (mode PHP_OUTPUT_HANDLER_START ? 1 : 0);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
Jared Williams wrote: Don't think that's what he said... More like... assert(is_object($foo) || is_array($foo)); // ensure strictly conforming $json = json_encode($foo); Which is, for all intents and purposes, the same thing. (Since you can't pass json_encode(34) for strict JSON). PHP has always erred on the side of Just do it, and punting the Do the right thing to the consumer. Maybe passing an E_STRICT error would be the right combo of 1 and 2? Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Ilia Alshanetsky wrote: The Windows are available as well at the following URL: http://windows.php.net/qa/. The number of changes since the last RC were fairly minimal and it is my opinion we are ready for the final release come Thursday next week. As usual please test this release and report any bugs that you may find, pending any new critical issues the final will be available shortly. This is likely a quirk in my Windows setup, but when I run RC2 and RC4 I get the error This application has failed to start because MSVCR80.dll was not found. Is this an artifact from the new Windows build system? Other than that, all tests pass on HTML Purifier. :-) Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Pierre Joye wrote: It should not use MSVCR80.dll as it is only for VC9. Can you try with a clean install and/or using a snapshot (5.2, http://windows.php.net)? I will try the snapshot very shortly. I did a little more poking around and php_curl.dll appears to be the culprit, not php.exe. There's no manifest on the dll, though, which is puzzling. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Pierre Joye wrote: It should not use MSVCR80.dll as it is only for VC9. Can you try with a clean install and/or using a snapshot (5.2, http://windows.php.net)? I will try the snapshot very shortly. I get the same error from php_curl.dll in the snapshot. I did a little more poking around and php_curl.dll appears to be the culprit, not php.exe. There's no manifest on the dll, though, which is puzzling. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Pierre Joye wrote: Are you sure you are using the right php/php.ini/extension? Yep. (Errors omitted for brevity) $ phpv 5.2.7RC5-dev --version PHP 5.2.7RC5-dev (cli) (built: Nov 23 2008 11:39:53) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies $ phpv 5.2.7RC5-dev --ini Configuration File (php.ini) Path: C:\Windows Loaded Configuration File: C:\Software\PHP\versions\5.2.7RC5-dev\php.ini My version dependent php.ini looks something like: ; This portion is automatically generated for PHP 5.2.7RC5-dev extension_dir = C:\Software\PHP/versions/5.2.7RC5-dev/ext extension = php_mcrypt.dll extension = php_mbstring.dll extension = php_curl.dll extension = php_exif.dll extension = php_gd2.dll extension = php_mime_magic.dll extension = php_sockets.dll extension = php_imap.dll extension = php_ldap.dll extension = php_ming.dll extension = php_xmlrpc.dll extension = php_gmp.dll extension = php_mysql.dll extension = php_mysqli.dll extension = php_xsl.dll extension = php_pdo.dll extension = php_pdo_sqlite.dll extension = php_sqlite.dll extension = php_gettext.dll extension = php_zip.dll I tried on a clean system (with no crt 8.0 around) and it works. As a second check, I loaded the extension and php in a dependency checker (snapshot and release), and both rely on the good old VC6 CRT. I'm going to load up my Windows XP virtual image and see what happens when I try running php. Will report. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Pierre Joye wrote: Are you sure you are using the right php/php.ini/extension? Yep. (Errors omitted for brevity) $ phpv 5.2.7RC5-dev --version PHP 5.2.7RC5-dev (cli) (built: Nov 23 2008 11:39:53) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies $ phpv 5.2.7RC5-dev --ini Configuration File (php.ini) Path: C:\Windows Loaded Configuration File: C:\Software\PHP\versions\5.2.7RC5-dev\php.ini My version dependent php.ini looks something like: ; This portion is automatically generated for PHP 5.2.7RC5-dev extension_dir = C:\Software\PHP/versions/5.2.7RC5-dev/ext extension = php_mcrypt.dll extension = php_mbstring.dll extension = php_curl.dll extension = php_exif.dll extension = php_gd2.dll extension = php_mime_magic.dll extension = php_sockets.dll extension = php_imap.dll extension = php_ldap.dll extension = php_ming.dll extension = php_xmlrpc.dll extension = php_gmp.dll extension = php_mysql.dll extension = php_mysqli.dll extension = php_xsl.dll extension = php_pdo.dll extension = php_pdo_sqlite.dll extension = php_sqlite.dll extension = php_gettext.dll extension = php_zip.dll I tried on a clean system (with no crt 8.0 around) and it works. As a second check, I loaded the extension and php in a dependency checker (snapshot and release), and both rely on the good old VC6 CRT. I'm going to load up my Windows XP virtual image and see what happens when I try running php. Will report. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Pierre Joye wrote: Please try in the cmd line: cd C:\Software\PHP\versions\5.2.7RC5-dev\ext php.exe -n -d extension_dir=ext -d extension=php_curl.dll -m C:\Users\Edwardcd C:\Software\PHP\versions\5.2.7RC5-dev\ext C:\Software\PHP\versions\5.2.7RC5-dev\extphp.exe -n -d extension_dir=ext -d extension=php_curl.dll -m [PHP Modules] bcmath calendar com_dotnet ctype curl date dom filter ftp hash iconv json libxml odbc pcre Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zlib [Zend Modules] And no error. That's very curious! Maybe it's two extensions causing the problem? I'm going to twiddle with my php.ini some more. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Edward Z. Yang wrote: And no error. That's very curious! Maybe it's two extensions causing the problem? I'm going to twiddle with my php.ini some more. My fault; the php.exe being executed was my 5.2.6 in the path. When I run it on the real executable, I get: C:\Software\PHP\versions\5.2.7RC5-devphp.exe -n -d extension_dir=ext -d extension=php_curl.dll -m [PHP Modules] bcmath calendar com_dotnet ctype curl date dom filter ftp hash iconv json libxml odbc pcre Reflection session SimpleXML SPL standard tokenizer wddx xml xmlreader xmlwriter zlib [Zend Modules] And I get an error. I tested on another Vista machine and an XP virtual machine, and I did NOT get the error, so it's something wonky in my configuration. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.7RC4 Testing
Edward Z. Yang wrote: And I get an error. I tested on another Vista machine and an XP virtual machine, and I did NOT get the error, so it's something wonky in my configuration. When I clear my %PATH% variable, the error goes away. The culprit is *some* DLL in C:\Program Files\MATLAB\R2008a\bin\win32. So this entirely not a PHP problem. Thanks for looking into it! Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for new construct: nameof
Stan Vassilev | FM wrote: I suggest we introduce a new construct which will return a string when passed any identifier to resolve against the current file's use clauses: nameof Symbol\Name; With this identifier, the above example can be normalized to the following code: I second this suggestion. One thing that would be awesome is if we could drop nameof completely (i.e. all class/function names are first class data) like F::loadFunc(B\Baz), but I doubt it would be possible with the parser (at the very least, it wouldn't work for items without a namespace separator, since it could be construed as a constant). Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where do I find a fresh PHP 6 Win32 build?
Tore B. Krudtaa wrote: Why is it not built more often? Usually it's because the PHP6 build is broken on Windows. Check the latest compile logs; they'll usually tell you where things broke, and then you bug the appropriate people to get it fixed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where do I find a fresh PHP 6 Win32 build?
Tore B. Krudtaa wrote: Why is it not built more often? Usually it's because the PHP6 build is broken on Windows. Check the latest compile logs; they'll usually tell you where things broke, and then you bug the appropriate people to get it fixed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where do I find a fresh PHP 6 Win32 build?
Tore B. Krudtaa wrote: Why is it not built more often? Usually it's because the PHP6 build is broken on Windows. Check the latest compile logs; they'll usually tell you where things broke, and then you bug the appropriate people to get it fixed. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Strange phenomenon
Lars Schultz wrote: http://forum.hardened-php.net/viewtopic.php?pid=1650 I vaguely recall Suhosin patched var_export to handle non-ASCII characters in var_export in a safe manner; var_export is known to do funky things to Unicode/binary data in vanilla PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP mixin RFC
Jonathan Bond-Caron wrote: http://wiki.php.net/rfc/mixin It seems to me that class_mixin() is a bad idea for the core; it's more of a runkit type functionality than traits. After all, we don't allow dynamic inheritance, or dynamic interfaces... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Cases in which loadHTML doesn't exit
I've been debugging a case where a PHP installation doesn't have DOMDocument-loadHTML, but phpinfo reports that HTML is enabled (the normal reason why loadHTML would not be available) and that the API version of 20031129. Is there any other way to check for the compile-time constant LIBXML_HTML_ENABLED, and are there any known bugs with regards to its display? Thanks, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cases in which loadHTML doesn't exit
Antony Dovgal wrote: And even if there are, I don't believe they are on our side, since it's the same #ifdef used in two different places, no chance to get different values. Yep. I did more source diving and this should not be possible. Which means that whoever deployed this PHP (i.e. the hosting company) has been monkeying around with the source. :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
Marcus Boerger wrote: to be honest, what is wrong with svn for you? Do you branch off your own PHP? No, so what's wrong? To easy to use for 99.99% of people using PHP repository? But please (everyone) just think of it and don't comment anymore. As I said previously, my personal opinion has no matter in it. I'm just saying that Travis's proposal is a good one and retains many of the benefits of Git (esp. in patch preparation) especially if it's officially blessed. Cheers, Edward -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
Travis Swicegood wrote: On a slightly related note, would anyone else be interested in seeing a Git repository along side Subversion? Even if people can't commit to the Git repo, I'd be happy to help set it up with the ability for them to push changes back to the SVN repo once they've prepared their patches. That would certainly be nice! I would normally advocate a full switch from CVS to Git, but since it seems the general consensus is to SVN, a parallel Git repository would greatly aid those of us stuck on Windows with bjorked git-svn installs. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
Noah Fontes wrote: I think PHP implicitly follows any Location headers it can. That's probably not the right behavior, but for an automated process it's not bad. It's a configurable option (don't have the code in front of me, so no proof, sorry). You can set redirects = 0, and have http not follow any redirects. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
Edward Z. Yang wrote: It's a configurable option (don't have the code in front of me, so no proof, sorry). You can set redirects = 0, and have http not follow any redirects. Whoops, I'm talking about pecl/http, not the http wrapper. Disregard the above. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New flame
Asbjørn Sloth Tønnesen wrote: Some some minor inconsistencies, between Shift-JIS and Unicode. http://en.wikipedia.org/wiki/Unicode#Mapping_to_legacy_character_sets And I say good riddance! The yen/backslash conflation has given me plenty a PITA in the past. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]
Andrei Zmievski wrote:
Maybe TextIterator can be backported from HEAD, because it allows for
just that.
foreach (new TextIterator($str) as $c) {
...
}
IIRC, TextIterator is specifically designed for Unicode, letting you
iterate over codepoints, combining sequences, characters, words, etc. So
making it do all that would only make sense with intl, and even then not
really (as Stanislav points out performance-wise).
What I was suggesting was a shortcut to iterating over binary data; i.e.
byte by byte.
--
Edward Z. YangGnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Fabrice VIGNALS wrote: In mathematic, equal meen the same value AND the same nature. The follow fact could be frustrating : Usually, context is good enough to disambiguate between the cases. The most prevalent convention in programming languages is = is assignment, and == is comparison (PHP adds === only because of its type-juggling system). Other languages have = as comparison, and := as assignment. Donald Knuth uses = as comparison, and a left arrow (-) for assignment. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]
Stefan Walk wrote:
You're not learning from the mistakes of other languages (ruby in this case,
which removed Enumerable from String in 1.9) ... foreach makes no sense for
strings, because it's unclear what you want (with unicode terminology here,
as this is for php6):
for each byte for each codeunit for each codepoint, or for each line,
or ...
You bring up a good point. However, as a counterpoint, Python does allow
strings to be used as arrays:
s = 'asdf'
for c in s:
print c
In my opinion, it only makes sense for foreach to emulate the code
snippet I posted above: for binary strings, that means byte-by-byte, and
for Unicode strings, that means codepoint by codepoint.
But as I said, it would be neat. This is by no means an essential
feature, and I probably wouldn't be able to use it anyway for BC concerns.
if you want to use foreach in your example, just do
foreach (str_split($str) as $value) { ...
I would never do that, because it requires allocating an entire another
PHP array, more than doubling memory usage, just to iterate across a
string. If I'm doing this sort of heavy string processing, I probably
need some semblance of performance.
--
Edward Z. YangGnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
Larry Garfield wrote: $e = new Example(); $lambda = $e-myMethod(); $e-$lambda(5); That doesn't seem right at all, but that's how I interpret Essentially, closures inside methods are added as public methods to the class that contains the original method. Can you give an example of what that actually means? At first blush, this sets off warning bells in my head, I suppose because my notion of a lambda says that the lambda should not carry any baggage about the context it was created in. However, with further thought, I believe that binding the lambda's lexical scope to the place it was defined is: * Conducive to good coding (you will always be able to look outside the lambda to find out where the lexical variables are coming form) * Adds functionality, since anything you want to pass to the function via the callee's context can be passed via a parameter What would be neat, however, is the ability to rebind the lambda to another context. Also, I don't know how other languages do it (Python? Lisp?). -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]
Chris Stockton wrote:
Seems like you are missing some PHP programming basics. Strings are not an
array of chars, please go back to making ping pong in java c# or whatever
other little comp sci classes you took. PHP is not any of them.
Foreach(foo as $key = $char) {}, after learning, please be quiet and let
andi answer my question on his ideas he had for improvements to the existing
and once favored syntax.
PHP userland code may not treat strings as first class arrays, but
that's certainly how they are represented internally.
Anyway, it would be neat if we could get that foreach syntax to work. I
get sick of for($i = 0, $c = strlen($str); $i $c; $i++) very quickly.
--
Edward Z. YangGnuPG: 0x869C48DA
HTML Purifier http://htmlpurifier.org Anti-XSS Filter
[[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode and XML
Edward Z. Yang wrote: My proposal is to introduce a new filter (for the filter extension) which performs codepoint sanitization appropriate for HTML/XML contexts (alternatively, this could be an option on the FILTER_DEFAULT filter, which would be for Unicode strings, I assume). This filter would be turned ON by default, and users could turn it off using a special option. Thus, codepoint sanitization would work invisibly for users who don't care, and would be accessible to users who do (i.e. those who don't mind mucking around with unpaired surrogates or the like. This [1] gives quite a good explanation about what this is all about). Time to squeak. Are there any comments on this proposal? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode and XML
Chris Stockton wrote: I think that internal string handling so be very respective to the specification as you said. Perhaps code points which are not valid for a separate specification, protocol etc, the conversion should be done in the functions dealing with those formats. Like if extension family xmlfoo does not like null bytes or bom or high surrogates, whatever, then have xmlfoo_strip_invalid (bad name too ;p). The trouble is that no-such function exists for HTML output. ;-) We'd be adding another function to the htmlspecialchars($var) cadre. (A counter-argument is that most people have defined a function _() or the like for this sort of thing. I think PHP can do things out of the box, though.) SOLUTION? = Before I propose my solution, I believe we should distinguish between functions like strip_tags() and the conjectured xml_strip_invalid(). Here are the primary differences: strip_tags() * Most appropriate on outbound, when the original data is preserved * Makes clear changes to what the user sees * Only used some of the time, universal application (i.e. magic quotes) is not a good idea xml_strip_invalid() * Most appropriate on inbound, as these codepoints are not supposed to be used at all. * Most of these forbidden characters are invisible, if/when they show up and don't cause fatal errors] * What works for XML almost works for everything, except binary data (notably), which shouldn't be in Unicode anyway. My proposal is to introduce a new filter (for the filter extension) which performs codepoint sanitization appropriate for HTML/XML contexts (alternatively, this could be an option on the FILTER_DEFAULT filter, which would be for Unicode strings, I assume). This filter would be turned ON by default, and users could turn it off using a special option. Thus, codepoint sanitization would work invisibly for users who don't care, and would be accessible to users who do (i.e. those who don't mind mucking around with unpaired surrogates or the like. This [1] gives quite a good explanation about what this is all about). The filter would also work auto-magically on traditional retrieval of values using the $_VAR super-globals. It would hook in with the regular JIT decoding of GPC (as described here [2]) and cannot be turned off, except by reading in by binary (which I do not know how to do). As some extra functionality, filter should make it easy for users to sanitize inputs to only contain codepoints of certain ranges. Because this functionality would hook into the decoding process, it would be much faster than using a TextIterator and hand-screening out codepoints. Of course, this functionality should support Unicode properties. [3] It would be interesting to survey what other languages (such as Python) do in said situations, although PHP is in somewhat of a unique position due to its legacy. Let's do this, and let's do this right. DISCLAIMER: I'm not sure anyone even cares about this issue. I mean, surely, the PHP devs have bigger fish to fry. But I think it is important, and I'll keeping squeaking about it. I can RFC-ize this if desired. Thanks all for reading this far. [1] http://xml.coverpages.org/unicode30Ann19990918.html [2] http://marc.info/?l=php-internalsm=116631089122369w=2 [3] http://docs.php.net/manual/en/regexp.reference.php#regexp.reference.unicode -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Unicode and XML
In PHP 6, incoming user data will automatically be in (unicode) form. (That is, assuming that the JIT functionality for converting gets implemented). One of the implementation details I'd like to consider involves non-XML and/or non-SGML codepoints inside markup. As per the Unicode specification, it is perfectly valid for a Unicode string to contain the codepoints U+ (null byte), U+ (non-character) and friends. However, it is not valid for an XML document to contain these characters; either of these will result in a fatal error. Classically, it was very difficult for PHP scripts to implement UTF-8 support completely correctly. Many implementations check that the UTF-8 is well-formed, but neglect to strip out null-bytes and the like. I consider validation/filtering against the XML char production (or perhaps even more restrictive, as that allows some control characters not allowed in HTML). How should we go about making this easy in PHP 6? Perhaps a web_encoding (terrible name, I know) function is in order? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC doesn't work on Windows?
Christian Hoffmann wrote: No, why should it? The cache is shared perfectly fine if you let PHP handle the process spawning (i.e. increasing PHP_FCGI_CHILDREN instead of running php-cgi -b (or whatever) multiple times). As phpxcache mentioned, that's not an option in Windows. Are you running Windows or Linux? I'm sure APC works on Linux; I'm curious about Windows. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC doesn't work on Windows?
Rasmus Lerdorf wrote: We don't have any active developers contributing to APC on Windows at the moment. We try to not do stuff that will break Windows, but beyond that we rely on people interested in that platform to step up and help out. I wish I could say, Yes! I'm interested in helping out! but I don't know enough about this area to really do anything useful except complain that things aren't working. When I get a chance, I'm going to try to set up APC on a clean Windows Vista install with the pre-compiled binaries. If it still fails, I give up and figure out how to install APC on Ubuntu. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC doesn't work on Windows?
Arvids Godjuks wrote: Use XCache instead - it's simple, fast and stable. APC is far more complex and unstable (is't like code for code) I wouldn't dare host a production website on a Windows website ;-). I'm much more interested in getting APC running for testing purposes; seeing how nicely my code plays with the opcode cache, whether or not a different include scheme would result in better performance, etc. Testing with XCache would be helpful (and I will certainly look into it), but APC is the industry standard and my first priority. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] APC doesn't work on Windows?
I don't really care either way, but if it's a well known fact, might as well stop trying. Does APC work on Windows? I recently submitted a patch to fix the snaps.php.net compilation of APC, but for any non-trivial script (interestingly enough, apc.php and and phpinfo() work fine), APC segfaults or otherwise fatally errors. Some errors I've seen include: [apc-error] Cannot redeclare class simpletest, referer: http://localhost/ on code that works perfectly without APC. I've scanned the bug list and there are quite a few reports of APC not working on Windows--so, is this generally known to be the case? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] APC doesn't work on Windows?
Jared Williams wrote: I'm running php 5.2.5 NTS with APC 3.1.0-dev. It works, but not without some issues, like occasionally get a FastCGI process crashing which I suspect is APC. Hello Jared, Doesn't running APC under FastCGI kind of defeat the purpose of APC? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]
Steph Fox wrote: What concerns me at this point is that we could and should be telling PHP users how to future-proof their code during the move from PHP 4 to PHP 5. If we can get a fix on that now and get word out, we'll have made their future migration path *much* smoother. As far as I can tell, it's effectively impossible for anyone who wants to support low PHP 5 versions. That's because the b prefix wasn't introduced until PHP 5.2.1, and that prefix is *crucial* to future-proofing any code that deals with binary data. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]
Andi Gutmans wrote: The idea here was to find volunteers who'd try and run their apps and some standard apps on this so we can figure out what the migration path looks like. That'd also give us the necessary data point to make a decision on default for strings. I think none of us right now truly knows what to expect. As I a PHP developer on Windows, I pay very close attention to development work on PHP and regularly test my code against PHP 5.3, hand-built from the CVS. Nearly all of the PECL extensions are broken on Windows for PHP 6. The http extension has a very nasty problem: its fatal error appears to loop nearly ad infinitum. This makes compiling snaps locally very difficult--I've given up. Why is the log file 4.4 MB long? Also, as stands it appears most non-trivial applications are fairly broken. Those issues need to be resolved first, before we toss Unicode onto the pile. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode progress [Was: unicode.semantics ad infinitum]
Edward Z. Yang wrote: Also, as stands it appears most non-trivial applications are fairly broken. Those issues need to be resolved first, before we toss Unicode onto the pile. I retract this statement; I didn't realize we had already turned on Unicode semantics. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Float comparison
Marcus Boerger wrote: Maybe you should have a look into PHP's bcmath extension. PHP's arbitrary precision math handlers are woefully inadequate. I mean, you can't even take the nth root or a logarithm with bcmath! (gmp isn't much better). (However, this has nothing to do with the floating point comparison argument.) -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.6RC5 windows build available
Pierre Joye wrote: http://pecl2.php.net/downloads/php-windows-builds/ Woohoo! That's pretty awesome! -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Help with calling PHP functions
Dhiru Pandey wrote: I am trying to figure out a way to invoke PHP functions directly i.e. bypassing the PHP compiler (scanner and parser). For now it would be great if I can get some help calling them from C. Ultimately I would like to call them from Java. It's not difficult to call PHP_FUNCTIONs if you're inside PHP: you create a zval with the appropriate callback value (a string if you're dealing with global PHP functions) and then use call_user_function. You can find detailed instructions here: http://www.php.net/~wez/extending-php.pdf Can't help you for the other, although Extending and Embedding PHP by Sara Golemon, George Schlossnagle and Wez Furlong covers that topic, I think. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Help with calling PHP functions
Dhiru Pandey wrote: Thanks for responding. May be I mis-wrote. What I would really like is a way to call the native c functions of the php implementation directly (bypassing the PHP compiler) like: PHP_FUNCTION(str_repeat) PHP_FUNCTION(addcslashes) etc. In other words I would like to invoke this functions directly thru C or Java. I do not want to callback into a PHP script user function Callback works with the native C functions too. It'll be pretty nasty trying to get all of PHP's macros to work from scratch. Just use the infrastructure that's in place already. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Help with calling PHP functions
Edward Z. Yang wrote: Callback works with the native C functions too. It'll be pretty nasty trying to get all of PHP's macros to work from scratch. Just use the infrastructure that's in place already. Sorry about the double-post; I should clarify: I mean that callback works with PHP functions that were implemented in C. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Const-correctness with Zend
I'm getting persistent const qualifier warnings with MSVC 2005 Express, along these lines: ..\extra\uriparser\uriparser.c(227) : warning C4090: 'function' : different 'const' qualifiers where line 227 looks like add_next_index_stringl(path_array, walker-text.first, walker-text.afterLast - walker-text.first, 1); ...where walker-text.first is a const char*. Now, because Zend is duplicating the value, it should be possible for this pointer to be const without causing warnings. (The alternative to estrndup it myself and not use duplicate, but that kind of defeats the purpose of duplicate, doesn't it?). As it turns out, it appears this message appears elsewhere in extensions too (just grep the Windows snapshot logs for C4090: 'function'). Since C doesn't support function overloading, this would probably mean macro-fying the relevant functions in the core to call separate duplicate and non-duplicate functions. In addition, the ZVAL_ macros would need to somehow add a const qualifier to the temporary string pointer if duplicate is true (I don't know if that's possible or not). I can produce a patch, although monkeying around in Zend is something probably best left to the experts. Still, I'm wondering if this would be a good idea or not. Code-wise, it should be fully backwards and forwards compatible (warnings simply disappear in newer versions), although it wouldn't be binary compatible. Or you could just tell me to estrndup. Thanks! -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Return type hinting patch
Sam Barrow wrote: Attached is my return type hinting patch. [snip] I have a question independent of syntax/design-concerns: does this patch utilize typed returns to afford performance benefits to userland code that use it? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unresolved external symbol __mysqlnd_debug
Antony Dovgal wrote: Is this HEAD? Or 5_3 ? 5_3. HEAD has way too many errors and failing extensions on Windows for me to care right now. :-) -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Unresolved external symbol __mysqlnd_debug
Johannes Schlüter wrote: Please do a cvs up and try again, thanks, mysqli working like a charm, thanks! -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Unresolved external symbol __mysqlnd_debug
I'm getting this fatal error compiling mysqli under Windows: Creating library Release\php_mysqli.lib and object Release\php_mysqli.exp mysqli_api.obj : error LNK2019: unresolved external symbol __mysqlnd_debug referenced in function _zif_mysqli_debug Release\php_mysqli.dll : fatal error LNK1120: 1 unresolved externals A similar error is occuring in the snapshot builds at snaps.php.net. Where can I get a more recent version of the library files? (if that is the problem?) -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] intl naming
Steph Fox wrote: So please, yes, keep the procedural way as an option, make it possible for people to use PHP without their having to be computer scientists first. The moment the language loses that, it has nothing special to offer any more. +1 Nothing beats procedural for the quick and dirty prototype. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The jump operator
Richard Quadling wrote: Is there use case that can be used for the documentation? Two big ones I can think of: Multi-loop breaks and parsers. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: FW: [PHP-DEV] memory corruptions in APC env when using references or extract(..., EXTR_REFS) [was re: references / zend_assign_to_variable / IS_CONST operands in APC]
Kannan Muthukkaruppan wrote: We are on 5.2.5. Download a snap/rc and check it out on that. Esp. 5.2.6, which will be officially released soon. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_5_3 GOTO?
David Coallier wrote: See http://marc.info/?l=php-internalsw=2r=1s=Backporting+to+5_3q=b As far as I know (and I was following that conversation), there was no discussion about the new goto keyword conflicting with existing code. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Backporting to 5_3
Stanislav Malyshev wrote: This is weird... I wouldn't go as far as saying nobody uses it - since experience shows there's somebody somewhere using any weird combination of PHP features imaginable - but it's definitely a strange code. Even though, I think since it's functionality drop, we may want to wait with it, unless it doesn't work anyway (e.g. produces segfaults in some cases). Did a little poking around. The only gotcha seems to be that the feature doesn't work when used with a literal string: list($b) = 'asdf'; // $b is NULL -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Allow unsetting headers previously set by header()
Christian Schmidt wrote: What do you think of the general idea of being able to unset headers? And what do you think of my patch? If you need this kind of flexibility, I recommend you make an HttpHeaders class which manages these things and then sends them when necessary. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] making var_dump and var_export even better
Stanislav Malyshev wrote: Also, about circular references. Isn't it possible to reuse the circular recognition from print_r and actually write out a reference to the offending piece? For var_export it isn't possible since there's no way to refer to the value being exported. I know this is a little hackish, but what if we inserted a NULL in that location, and then appended a few PHP statements that created the references? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_ini_parser.c fails to create in latest PHP6
Antony Dovgal wrote: He's using snapshots, so that should not be required. I'd say somebody forgot to upgrade re2c on the snaps machine. Btw, when is 0.13.4, the currently required version, going to be released? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Rasmus Lerdorf wrote: Well, I actually have years of experience taking apps and making them run under my strict default filter. And it tends to not be very many changes, if any at all. In the O'Reilly case it gets changed to O#39;Reilly which for a pure web app is fine. If all input consistently gets changed the same way then you can store O#39;Reilly in the backend and a search will still find it since the search query itself will be encoded the same way. If you have non web tools working with the same backend data, then you may have a requirement to store it raw, in which case you'd need to poke a hole in your data firewall. Rasmus, I'm sure these techniques work very well in practice. However, it's important to note that it's still an optimization, a step down from an ideal standard which would involve keeping raw data in the database. In theory, the data in its purest form, with no extraneous escaping, would be stored. In practice, most data will be used in a web context and thus, as you note, escaping it as #39; is perfectly acceptable. I've always advocated storing both the pure data and the escaped version (in a kind of cache) in the database, because if you store just the escaped version you don't have any easy way (besides decoding) to get the raw version back. Of course, this doubles the storage requirement. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Rasmus Lerdorf wrote: Sure, although if you are going to store the raw, I think it is pointless to store the escaped version. Yeah, I was thinking more of escaping data that is computationally expensive; such as bbcodes or wikitext = HTML. I am not advocating storing it either way, I am simply saying that by default you should never work with raw user data. [snip] If you forget to fetch the raw or if you forget to re-filter it through the appropriate filter for whatever backend, then chances are your application won't work, or the user will see strange output, but at least you will be failing safe, instead of failing insecure. I understand that and how your methodology works, but I've always thought there was something fishy about it. I suppose this is the reason: the default won't always be secure, because HTML (and other formats too, I suppose) require a great variety of types of escaping. Say we're placing data in a href= attribute; the default HTML escaping will protect against breaking out of the quote, but the user can still pass javascript:xss() and cause problems. There are two levels of escaping/validation that need to happen here: the HTML escaping, and a URI validation. The default can lull users into a false sense of security, especially for more subtle vectors, whereas if you force people to be explicit you've at least *attempted* to make them think about what output format they should be using. Either that, or make it so that the only way for a developer to output something like that is a manner that also supplies the context (for example, using a DOM builder). Of course, careless developers will still make careless mistakes, and I agree that a sensible default will fix the majority of these issues. Just not 100%. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Rasmus Lerdorf wrote: The best you can do is provide sensible default actions and make sure people realize that it isn't the entire solution. But I don't think throwing our hands in the air and doing nothing to help the developers is the answer just because there are such contexts that can't be solved by filters. I believe we're in agreement. But I don't know if there's any way to do this while not fundamentally redesigning PHP and changing every PHP tutorial on the Internet that says you should ?php echo $_GET['data'] ? (a lot, apparently: http://www.google.com/search?q=%22echo+%24_GET%22 ). The users who use filter are the ones who actually know what the right thing is to do, and would benefit the least from this (although, as you mention, they would still benefit, as smart developers can still be careless!) But there's nothing stopping a newbie developer from dropping a few echo's except some sort of auditing strategy; discipline still plays a large role in it. Of course, adopting a less-obvious syntax for raw data will make it more evident when PHP's easyinsecure capabilities are used... -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: halo 3 tournaments - 4v4, 2v2, 1v1 and FFA tournaments weekly athalo3-tournaments.com
halo3-tournaments.com wrote: www.halo3-tournaments.com [snip] Can we get someone to delete this message from the newsgroup archives? Normally, I wouldn't mind, but this one's dated to 2036 and my news client (Thunderbird) doesn't let me hide or delete it, so it's constantly floating at the top of my list. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Double quoted NOWDOC is HEREDOC
Steph Fox wrote: Just one. Why? Probably to be consistent. Let's say a hypothetical user learns to use NOWDOC before HEREDOC: which syntax are they more likely to use; 'NOWDOC' or HEREDOC. However, I too am -1 because this smacks of the Perl philosophy of more than one to do things, which, in terms of syntax, is completely unnecessary. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_5_3) /main SAPI.c SAPI.h main.c php_globals.h /sapi/apache mod_php5.c ZendEngine2 zend_execute.h zend_execute_API.c
Rasmus Lerdorf wrote: exit_on_timeout patch Hi Rasmus, I noticed that this patch modifies the Zend Engine API slightly. Does this translate into any changes that need documentation at php.net? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /main SAPI.c SAPI.h main.c php_globals.h /sapi/apache mod_php5.c ZendEngine2 zend_execute.h zend_execute_API.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rasmus Lerdorf wrote: No, I don't think so. I checked all extensions in php cvs, including pecl, and none of them call zend_set_timeout() which is the function that was changed. And I can't see any foreign extension needing to call that function either. Gotcha. Just making sure. :-) - -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4IHdqTO+fYacSNoRAj/qAJsFUwEhTrzeHcKc44Lsgh4v2XaffwCdH9c4 pG0iMatqFnqtNgd9CsOhT2E= =aLk6 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt strip_t
Marcus Boerger wrote: - Rewrite scanner to be based on re2c instead of flex The full patch is available as: http://php.net/~helly/php-re2c-5.3-20080316.diff.txt This is against php-re2c repository version 98 An older patch against version 97 is available under: http://php.net/~helly/php-re2c-97-20080316.diff.txt This looks like a fairly big change, with changes to tests, although glancing over the patch they all seem to be syntactical/format-wise. Does this commit cause any behavioral changes? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt strip_ta
Marcus Boerger wrote: - the tokenizer works a bit different as tokenizing works better now, that is uses less tokens. - the scanner is about 20% faster, overall execution is about 2% faster when not using compiler caches like APC - in some edgecases error messages are no longer corrupted I'm not so much interested in performance changes as in end-user behavior changes; will this affect *any* PHP code, or is it completely backwards-compatible? (not counting multibyte support, of course) Some possible areas I'm thinking based on browsing the patch are the tokenizer functions, the ini parser interface, filename limits, cli interface, etc. It looks like some of the compilation docs/toolsets will need to be updated. I'll try compiling 5.3 on Windows later today. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt stri
Marcus Boerger wrote: Of course it affects that kind of tools. But the scanner was changed a lot of times for 5.3 already, so you have to do that anyway. That is the cost of making progress - changes. Agreed; I'm in favor of changes. But to make things as painless as possible those changes should be well-documented. For me, the Windows build is currently broken; it looks like nmake is still trying to use flex to generate the parser code (i.e. the Windows build scripts weren't updated). Wondering if I should punt to Elizabeth. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ANNOUNCE] Scanner to be based on re2c
Here is a patch that appears to fix the Windows build: http://www.thewritingpot.com/patches/php-re2c-windows.patch I made re2c required; if pre-generated files are supplied, however, we might be able to get away without it. I also had to download re2c binaries from http://sourceforge.net/project/showfiles.php?group_id=96864 and put them in my path. Whoever's maintaining zip.zip will want to update it. It appears Visual C++ 2005 Express does not support gotos to variable labels (it does support vanilla gotos out of the box, however). So I didn't bother porting the goto check code. Someone might want to do that later if we start supporting other compilers. Zend-related source files appear to have compiled successfully; re2c didn't give any output and exited with error code 0 (I assume it worked). -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt stri
Marcus Boerger wrote: Yeah, thats right. That is also the reason why we spent several weeks working on thjise with a small team prior to comitting the work. Also note that plans for this move are in place for over two years now. And of course we document changes as we find them, though none of the above looks like it needs to be mentioned anywhere. Sounds good. If there are no intended documentable changes, this will be fine for now. Side-effects can wait. :-) Yeah kick her! :-) I've updated one of the scripts now and we will comitt the others soon as we find them. If you know of anything we seem to have overlooked let us know. And if you stumble about changes you think need documentation, then *please* let us know. Haha, beat me to the punch. I have one more suggestion: in win32/build/config.w32 remove the requirement for flex (see http://www.thewritingpot.com/patches/php-re2c-windows.patch ). I'm not sure about requiring re2c? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 43053 - scientific notation
Antony Dovgal wrote: In 5.2.1 string-to-double routines were changed to use BSD licensed code (previous version was LGPLed). What you see is just an unintentional side-effect of this update. Side-effect or not, it looks like the change was pretty major and some documentation should be added. There, really, are two questions: 1. What is the new behavior? 2. Is the new behavior correct? It looks like, from the bug report, two separate issues are being reported. The first involves large integers, which I can't reproduce on w32 builds for 5.2.2 and 5.2.5, and should have anything to do with string-to-double. The second involves floats to strings. I'd argue that the first case shouldn't be happening, and I don't see it, but nate's report appears to be consistent with this sort of thing. The float complaints, however, is almost certainly all bogus, and needs better documentation. -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_5_3) /main fopen_wrappers.c
Dmitry Stogov wrote: Disable path resolution for filenames with stream wrappers More careful check for relative pathes (./xxx and ../xxx) Hi Dmitry; does this change behavior for any code that might exist already, or does it simply fix a bug? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
