Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/27/2012 6:46 PM, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). Can you expand explain this, with an eye to resolving 61172? Are you saying Apache 2.4 'httpd -M' might not return the mpm? The mpm is now a loadable module, not compiled in. The recommended default mpm is now event, the recommended .rpm proposes shipping event/worker/prefork, all as modules. The user is *free* to switch mpm's at any point by simply editing their httpd.conf file, so what was a non-threaded server becomes a threaded one. httpd -l will not return what you want, httpd -M will, but is not the right solution... # bin/httpd -l Compiled in modules: core.c mod_so.c http_core.c # bin/httpd -M Loaded Modules: core_module (static) so_module (static) http_module (static) ... version_module (shared) mpm_event_module (shared) unixd_module (shared) ... The httpd -V command was always the correct way to test for threaded'ness, which would allow supporting an mpm which was not known to you. Again, it will only reflect the currently loaded module (and fail if no MPM is loaded); # bin/httpd -V Server version: Apache/2.4.1 (Unix) Server built: Feb 28 2012 10:37:32 Server's Module Magic Number: 20120211:0 Server loaded: APR 1.4.5, APR-UTIL 1.3.12 Compiled using: APR 1.4.5, APR-UTIL 1.3.12 Architecture: 64-bit Server MPM: event threaded: yes (fixed thread count) forked: yes (variable process count) ... Editing httpd.conf... s/event/prefork/ results in ... Server MPM: prefork threaded: no forked: yes (variable process count) In 2.2 the default MPM became worker. In 2.4 the default MPM is now event, so prefork hasn't been the default in some 7 years. The only sensible build for mod_php is ZTS, which will load and operate whichever mpm is loaded by the user. The only sensible single thread environment is cgi (enhanced, of course, with fastcgi!) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/28/2012 12:26 PM, Stas Malyshev wrote: so prefork hasn't been the default in some 7 years. The only sensible build for mod_php is ZTS, which will load and operate whichever mpm is loaded by the user. The only sensible single thread environment is cgi (enhanced, of course, with fastcgi!) Please note that TS build is slower and has higher memory requirements (due to TS locks and TS data structures) so having it as only build may not be optimal. Of course, which is why a cgi build is /also/ useful. But I just don't see performance complaints, they are almost always reliability or configuration issues. If you are running that close to the edge that the 15% performance penalty kills your box, you were well past time to scale to more boxes or to review the PHP code itself for performance issues. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/28/2012 3:41 PM, Sebastian Bergmann wrote: On 02/28/2012 02:44 PM, Christopher Jones wrote: Build PHP with ZTS enabled by default. Allow it to be explicitly disabled during 'configure' Why punish everyone by default because of Apache? Does not make sense to me. What is so difficult to grok about 1. setting up php-cgi to use fastcgi as the httpd default. 2. having parallel non-zts and zts installs of php (notably with only non-zts cli and cgi sapi's) with two different lib paths. Multiply by two again if you have parallel i686 and x86_64 installs. All of these are packager's questions anyways, as so few users do this for themself, most hosters aren't rebuilding php either. PHP would be a much nicer, friendly and more civilized development list if it borrowed only one phrase from the Perl community; TMTOWTDI. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On 2/27/2012 6:58 AM, jpauli wrote: PHP through mod_php on Linux should compile without ZTS. configure script searches for apxs binary and tries to invoque apxs -q MPM to figure out what MPM has been compiled in Apache for the TS flag to be defined or not (thus, activating PHP ZTS, or not). Right... Mainly on Linux, Apache should have been installed with prefork MPM ans apxs -q should return that, then configure should not define PHP_BUILD_THREAD_SAFE. No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux distros have moved away from it... Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). The only mod_php loadable under any circumstance is TS enabled. If you want php/linux single-child, fastcgi is the only rational approach. I dont know anything about windows, sorry Always threaded. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit Windows builds
On 1/19/2012 5:29 AM, Pierre Joye wrote: 2012/1/19 Ángel González keis...@gmail.com: Such binaries wouldn't be compatible with IIS, but mingw seems preferible to the legacy VC6 for use with the oficial Apache binaries. A couple of things to remember; msvcrt.dll is quite actively maintained, even when it's maintained against the interests of php or the c language standards bodies. This would not be true of msvcr70.dll, for example. Actively supported is msvcr100.dll, of VisualStudio 2010, and that is what the httpd project expects to ship some httpd 2.4.0 binaries with. But the msvcrt.dll itself is neither less or more maintained so far than the per-studio-release flavor. It's a shame that the NT/kernel team and the VisualStudio team simply can't get along. Any mingw/gcc build is going to bind right back to msvcrt.dll, nullifying whatever train of thought you were pursuing. There are php-specific defects that MS has chosen to err on the side of incompatibility to spec. There is no such thing like official apache binaries, they provide some as conveniences. Just as with php; these are open source, we give you the source. What you the user proceed to do with it is with our blessings :) This is one of the advantages of keeping build systems and dependencies as accessible as possible, something I consider a flaw in php's win (and aix, solaris and hpux support), and a laudable goal of the coapp effort (all the way through pushing upstream their own shallow fork fixes). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit Windows builds
On 1/18/2012 6:13 AM, Lester Caine wrote: A much better reason for not supporting the build is probably that the 64bit compiler is not available in the free development stack? We have to buy a development stack to get the 64bit compiler which blocks rather than working with the publicly available process :( But actually that is a better reason for supplying a 64 bit build, and why others are providing that service. Actually, no. There are any number of free mechanisms to build 64 bit code. The root problem is that Windows WIN64 is a 64P architecture. Linux and *nix variants, on the other hand, are 64ILP or 64LP. Meaning Windows has longs/ints which are undersized compared to the *nix brethren. The old and stale abuse such as unsigned long X = (unsigned long)pY; will not do what the author intended. This means all packages ported to *nix 64 bits may have very serious flaws which have not been fixed for *Windows 64 bit* architecture. I'd anticipate CoApp identifying and resolving most of these applicable to PHP over the coming months, but it is a non-trivial problem requiring a number of pairs of eyeballs to get right. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit Windows builds
On 1/18/2012 12:14 PM, Lester Caine wrote: William A. Rowe Jr. wrote: On 1/18/2012 6:13 AM, Lester Caine wrote: A much better reason for not supporting the build is probably that the 64bit compiler is not available in the free development stack? We have to buy a development stack to get the 64bit compiler which blocks rather than working with the publicly available process:( But actually that is a better reason for supplying a 64 bit build, and why others are providing that service. Actually, no. There are any number of free mechanisms to build 64 bit code. Could you elaborate on that? Building 64bit windows applications which are VC9 compliant would seem to need the 'official' compiler, and while I have not done a lot of looking, there was nothing being offered when I tried to set up the windows build environment form Pierre's original notes although that was some time ago. I ended up buying an M$ development pack to plug the hole. The SDK and DDK remain free with a minimal toolchain, including 64 bit compilers. Of course they aren't called that anymore, because things are only fun in the Windows world when they overhaul the glossary of terms every 3 years. You probably started with Express edition of Visual Studio, and I note that it claims not to support 64 bit. But the compilers in the SDK or WDK (Windows Drivers Kit formerly DDK) should solve your issue. I don't know offhand whether these contain visual studio 15 or 16. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Benchmarking ...
On 10/21/2011 4:42 PM, Lester Caine wrote: Stephen Zarkos wrote: Yes, I do:) Although the tests we've done are a bit different from this sort of benchmark. We typically do more load testing, where we have one or more load agent(s) each creating multiple virtual clients accessing one or more PHP pages on another physical server. I'm trying to factualize this and come up with a benchmark that I can rely on to check performance. The initial claim was that there was no advantage using 64bit builds, but I've re-run everything on the Vista box, and this is giving me 70 seconds on the x86 Apache/PHP but 60 seconds with the x64 build. This is confirming what I thought myself, and I would expect around 40 seconds on a 64 bit linux on the same hardware. I will try a live CD just to confirm that. This would suggest that something else is going on with the Windows7 setup for it to be 4 times slower? 4x sounds excessive, but in fact TS code is a significant performance penalty for windows, the only place where thread safety is supported. I'd challenge you to do a non-TS build on windows and set up an fcgid pool of php workers and compare -that- to linux. I'd expect very nearly identical performance, once you factor out kernel-specific differences in the link-loader/resolver. Those are likely two very different beasts. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/30/2011 5:02 PM, Stas Malyshev wrote: It looks like all of these are reproducible only on vc6 build and all have same issues with division and rounding, and all not reproducible on vc9 - which makes me thing it's some vc6 problem. Maybe the one Gustavo identified, or something like it. I'd be inclined to say recommendation for it would be to build it on vc9. Why wouldn't you address this with VC10? Is there some reason to use the already stale n-1 version? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/30/2011 10:36 PM, Rasmus Lerdorf wrote: On 1/30/11 8:30 PM, Daniel Convissor wrote: That's not an option for the large number of people who want to run PHP under Apache, let alone folks who don't have VC9 tools. The diff() code is mauling data types in undesirable, though easily fixable, ways. Aren't Apache VC9 builds readily available these days? From all I've heard, mod_fcgid is the way to go anyways, so isn't the whole discussion academic? It doesn't matter how php is built if you are loading the appropriate number of single process instances as fastcgi daemons. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/31/2011 5:23 AM, Pierre Joye wrote: hi, On Mon, Jan 31, 2011 at 5:36 AM, Rasmus Lerdorf ras...@lerdorf.com wrote: Aren't Apache VC9 builds readily available these days? http://www.apachelounge.com/download/ I forgot to mention it here again. These builds are not officially supported by Apache but work very well. Apache still uses VC6 (vc6 crt or compiler) for their releases. Or to say the same thing with different words, the ASF doesn't release binaries at all, they release source code. AFAIK apachelounge builds come together with no issues from the released source packages, although there is sometimes a small delay when they find a flaw, fix, and submit the fix upstream. But this doesn't really differ from any other linux distributor who ships httpd :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/ext/date/php_date.c trunk/ext/date/php_date.c
On 1/31/2011 1:43 PM, Pierre Joye wrote: On Mon, Jan 31, 2011 at 6:26 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/30/2011 5:02 PM, Stas Malyshev wrote: It looks like all of these are reproducible only on vc6 build and all have same issues with division and rounding, and all not reproducible on vc9 - which makes me thing it's some vc6 problem. Maybe the one Gustavo identified, or something like it. I'd be inclined to say recommendation for it would be to build it on vc9. Why wouldn't you address this with VC10? Is there some reason to use the already stale n-1 version? It does not matter what is the latest VC version. What matters is that VC6 is a dead cow and we won't support it anymore, [..] Which I think we agree with, but you answer is a non sequitur, if you are defining the 'next right solution', why deploy the n-1 build environment? You would just be applying that legacy to the next maintainer, whom like you, will ask you why they need to be dealing with VC 9 :) As a complete aside, Mladen reminds us on the httpd dev list that the Sun JDK's are built with VC 2003, and my other two data points were always what ActiveState offered for perl and python (and now, of course, what the strawberry perl offers). So while I'm not insensitive to the PHP community, those are the four major languages that could be deployed in-process which can suffer all sorts of incompatibility with one another, and with httpd itself :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/29/2010 7:47 PM, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. Is it that hard to at least review the mailing list archives before ranting? At least posters would sound like they have educated themselves on why what came to be, and argue sensibly for changes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On 10/29/2010 8:17 PM, admin wrote: obviously the old arguments didn't work, time to start anew. obviously you didn't stop to learn the art of persuasion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to trace a crash bug?
On 3/25/2010 3:53 AM, Johannes Schlüter wrote: Hi, On Wed, 2010-03-24 at 23:24 -0700, Thomas Hruska wrote: PHP 5.2.13 on Windows XP SP3 w/ Apache (PHP as a module) is crashing for me. I've tried to create a simple test case to reproduce but I'm not able to. Any hints/tips or a guide on how to debug this would be highly appreciated. I'm not adverse to debuggers and I have VS2008 Professional on this machine. On http://bugs.php.net/bugs-generating-backtrace-win32.php are instructions to create a stacktrace of the crash which might give a first indication where to look. Depending on where it crashes, you may also need to grab the symbols for your version of apache; http://archive.apache.org/dist/httpd/binaries/win32/symbols/, the zip unpacks neatly on top of your apache2.x directory tree. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance improvements
On 3/24/2010 6:41 PM, Stanislav Malyshev wrote: Hi! Wouldn't it suffice to add a field for the hash value and a flag that indicates its validity to zval instead of appending zend_literal everywhere? Enlarging zval would be costly (the engine uses tons of zvals) and may also be more complicated to track (all zval operations now would also have to take care to set the flag right - what if we forget in some extension to set it right?). I think it's better not to mess with zval. Is it time to consider that one zval isn't the answer to all puzzles? Perhaps a light and heavy weight zval make sense here, where the light zval makes assumptions about local scope, not reentrant/threadsafe, while a heavier zval could be used for objects and meta objects with general functionality including thread safety, redundancy, validity and scope?? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
On 3/16/2010 6:48 AM, dreamcat four wrote: Sure UTF-16 can make sense. But only if your external representations are also in UTF-16. So whats the default Unicode settings for MYSQL, POSTGRE, etc? Well, are they always set to UTF-8, or UTF-16? This is a very good point. The PHP project consumes some 30-odd libraries of extensions. How many do utf-8? How many do ucs2? Utf-16? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
If Unicode were the solution, the PHP project was on the right page with 6.0. Sure there remained work to do, but... How long did it take to realize UTF16 wasn't the end of the story? UCS-4 is the minimum to solve this, and we all agree that 32 bits aren't storing a single char in the western world, no way, no how. The UTF-8 solution is probably the right answer... you maintain 95% of char *UTF behavior, and you gain international character representation. The only Unicode OS I can think of offhand is NT, and of course they hit the UCS-4 problem early. They found this out 15+ years ago. Sure it doesn't appear as atomic, one Xword per char, but the existing library frameworks contain most of the string processing that is required. There is no 16-bit network transmission API that I can think of, you are still devolving to UTF-8 for client results. To move forward with accepting -and preferring- UTF-8 as the representation of characters throughout PHP, recognizing UTF-8 for char-length representations, and so forth, would do wonders to move forwards. And 8-bit octet data can be set aside in the same data structures. It is the straightforward answer, which is probably why Linux did not repeat Windows NT decision, and adopted utf-8. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with apache segfault
jvlad wrote: #2 0x2c145afb in apr_pool_destroy () from /usr/lib64/libapr-1.so.0 No symbol table info available. See http://httpd.apache.org/dev/debugging.html on how to grab the -win32-symbols.zip package. Unpack it over httpd and you will probably have more legible backtraces. Ensure you have all the debugging symbols for php you'll have something completely legible. aha, and /usr/local/src/php/php-5.2.9/Zend/zend_vm_execute.h is a very common path under Win32 :) Here? Yea, it is. But looking at the libapr-1.so.0 module, agreed that I've misread this :) @Rathnakar Konda, is it possible that php was compiled against wrong Apache headers? Did you install something like OS-supplied httpd-devel package to compile php or grabbed apache sources from their web site? I'm not used to seeing bad stack unwinds on unix, most people don't optimize that aggressively. If this is system-httpd, that's fine; if you installed an httpd package, there is likely an httpd-devel package that also includes the debugging symbols you need (unstripped). If not and you've built this, you can simply try -O0, or -g, or for httpd --enable-maintainer-mode, but offhand I can't think of a trivial way to simply avoid -strip, which is what you want for your build when things go wonky in your gdb where output. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with apache segfault
Rathnakar Konda wrote:
after observing lots of core dumps from apache, we got a different segfault and
its back trace is given bellow
#0 0x2aaab1c46688 in ZEND_FETCH_DIM_RW_SPEC_VAR_UNUSED_HANDLER (
execute_data=0x714ea6c8)
at /usr/local/src/php/php-5.2.9/Zend/zend_vm_execute.h:13204
opline = (zend_op *) 0x714e8798
free_op1 = {var = 0x2c1454fd}
you appear to have .pdb symbols for your php. Now you need them for
apache...
#2 0x2c145afb in apr_pool_destroy () from /usr/lib64/libapr-1.so.0
No symbol table info available.
See http://httpd.apache.org/dev/debugging.html on how to grab the
-win32-symbols.zip package. Unpack it over httpd and you will probably
have more legible backtraces. Ensure you have all the debugging symbols
for php you'll have something completely legible.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in HTTP stream context causes problems in SoapClient/get_sdl()
Hannes Magnusson wrote: On Sun, Jan 25, 2009 at 22:43, Giovanni Giacobbi giova...@giacobbi.net wrote: The problem turned out to be an invalid interpretation of the HTTP/1.1 protocol with Transfer-Encoding: chunked by the HTTP stream context, which caused get_sdl() to parse a WSDL including the chunk tags (hex numbers). Chunked encoding is used by Apache 2.0 when Content-Length is unavailable, the data content being sent is large enough, and the protocol is HTTP/1.1. PHP streams do not support chunked encoding, and I assume SOAP doesn't either (although it does reinvent bunch of things, I don't think chunked encoding was added). I thought the docs were quite explicit on the subject.. if not, please open a doc bug. Then there is a problem, HTTP/1.1 mandates support for chunked encoding. In Apache's case, the stream should be dechunked before being passed to cgi, fcgid or apache2handler. The appropriate EOF state should be signalled when the chunked stream is exhausted. So how you are seeing the chunk headers is beyond me. Perhaps this hop-by-hop header should be eaten in apache before passing headers to the application? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] build IDs proposal
Pierre Joye wrote: A VC6 extension is not compatible with a VC9 build (or the other way round). It crashes randomly depending on what the extension does (xdebug for one is really good for this test :). This is only true for specific combinations of extensions and 3p libs based on what resources the one grabs that the other releases. E.g. if the 3p lib calls malloc and expects the ext to call free(), those two must use the same msvcr. Similarly, an extension that close()'s a file handle allocated by php core, then those two must use the same. For most well partitioned API's this is simply not a problem. (e.g. for mod_perl which is anything but partitioned, it's a horrible situation.) If the additional info were a diagnostic form, that would be nice. As a roadblock to loading an extension? That's a nonstarter. The day after you ship Studio 9 builds (quit saying VC9 already! Studio 6 shipped VC12 a very long time ago) you recognize people will be also building with Studio 10? That's just the way these things go. So +1 for extra information; I can find that with the forever-distributed depends.exe tool anyways, but -1 to some blanket enforcement or for building this into the enforced fingerprint of php. And +1 for enforcing things such as zts by way of such a fingerprint. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Differences in VC6 and VC9 Windows builds and MSSQL Driver.
Uwe Schindler wrote: I am not sure, if VC6 can be dropped easily. E.g. some SAPIs that directly map into servers may have problems if using the wrong CRT. Until now, I had no time to build up a Windows Sun Java System Webserver and test it with both CRTs. The code compiles fine on the snaps box, but I am not sure, if the DLL loads into the server. Precisely. Note that httpd 2.4 (.next) will not be compiled with VC6, but may continue to use msvcrt.dll - if I successfully validate a proper method (which might rely on some sdk/wdk includes) for continuing to use this lowest common denominator crt with sources compiled on modern compilers, I'll be sure to send this feedback in. 99% certain that the classic method is simply wrong (link32 msvcrt.lib /ignore:msvcrXX.lib) since the correct clib headers corresponding to msvcrt are required to avoid abi issues. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
Greg Beaver wrote: Hi all, Let me make this brief: there will be lots of complaining about the namespace separator. Stop. Now. And if you had the common decency not to change the thread-id and subject some on this list might respect the spirit of your plea. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
William A. Rowe, Jr. wrote: Greg Beaver wrote: Hi all, Let me make this brief: there will be lots of complaining about the namespace separator. Stop. Now. And if you had the common decency not to change the thread-id and subject some on this list might respect the spirit of your plea. I should add that I'm guilty of marking-read entire-thread. having scrolled back, it's pretty clearly time for another Rasmus intervention into what -was- a technical discussion, a couple 100 posts ago. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Marcel Esser wrote: Using ::: as a namespace seperator would be great. A general rule of telephony dialing and other data input, three of the same character will too often be entered or recognized as two or four characters due to user or mechanical error. That's why when you see mnemonic phone numbers they rarely repeat three digits in the middle (three 0's at the end for example aren't subject to the excess fourth repetition problem). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] License for Windows binaries
Cristian Rodríguez wrote: 田中 裕一 escribió: Hi all, Could anyone tell me the license of the binaries and source code placed here? http://pecl2.php.net/downloads/php-windows-builds/ I am developing a commercial package software using PHP and I will build libraries and PHP my own. Is it ok to use Visual Studio project files in these zip files (http://pecl2.php.net/downloads/php-windows-builds/source/) or these binaries (http://pecl2.php.net/downloads/php-windows-builds/php-libs/) for our commercial product and distribute our product with those binaries? there is no restriction on using PHP in commercial products, as long you comply with PHP license http://www.php.net/license/3_01.txt you must also comply with the legal requirements of the needed libraries. Well, the binaries probably include c runtimes under liberal MS license. They might be kind and give you mysql and a host of other GPL features under a very restrictive license. PHP's license is, as Cristian says, very liberal and you have nothing to worry about until you link to something ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Suspendable requests for Apache
Rustam Abdullaev wrote: Hi, Is anyone working on a suspendable request support in PHP when used as a module in Apache? The 'Event' mpm should be there already, IIRC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ini-parsing, double quotes, windows in 5.3
Stan Vassilev | FM wrote: I have to agree, this kind of change would be very frustrating for Win32 users, even though the solution is that simple. Nobody reads update guides or installation instructions, they're used to write path like that and they'll continue to do it, so we'll have much more bug reports after the release if we keep it this way. Just try to imagine how much PHP installations will suddenly stop working after the upgrade. I do agree that this syntax is actually correct and it should have been done this way since the very beginning, but now it's too late for such changes, we have to put the old behavior back. I'm a Windows PHP user. It's never late for a change of that kind. Upgrading your PHP installation is officially a Big Event, and tweakin the ini is a one-time operation per upgrade, so I believe some people may be overestimating the pain it will cause. +1 There won't be any bug reports, if the ini parser detects improper backslash usage (i.e., using a backslash with a following character which doesn't form correct escape combination) and stops with informative and descriptive message explaining the parser changes. Then anyone who can read, will figure it out, and fix it. Nobody reads update guides or installation instructions ...until it breaks :) It can be spelled out clearly enough. The user just wants clear instruction or an easy hit on google. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Something to ponder on ZTS/TSRM
As far as the future direction of embedded PHP (and let's agree here we aren't talking about every application, for mass vhosters some fcgi or suid flavor of PHP is going to remain a better choice, and for others, so we can avoid that debate)... The next direction for server worker pools will likely be a threadless connection; while waiting for your POST body the php engine environment will most efficiently be parked and resumed on another thread. (Some code has been started in this direction at httpd although there are no corresponding 'engine' hacks yet for embedded language systems.) So although the new patches look great for a threading application, keep in mind that a more traditional zts mode may be worthwhile to retain. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #43941
David Zülke wrote: Am 21.08.2008 um 18:50 schrieb Rasmus Lerdorf: David Zülke wrote: Am 21.08.2008 um 18:41 schrieb Rasmus Lerdorf: David Zülke wrote: Am 21.08.2008 um 18:08 schrieb Rasmus Lerdorf: David Zülke wrote: Am 21.08.2008 um 03:34 schrieb William A. Rowe, Jr.: Stanislav Malyshev wrote: Hi! Are there any objections to incorporating bugfix for #43941 (fix for how json handles invalid UTF-8 sequences) into 5.2? I had some requests about it, right now it's only in 5.3+. Is there the alternative of substituting an unmappable character FFFD in place of the invalid sequence? This a a reasonable alternative behavior for some less stringent cases. (Yes, the fix is better than the status quo, but just taking this a step further). I agree, that would be quite reasonable and also more consistent with how UTF-8 works in other apps (browsers etc). Well, using browsers as the benchmark here is a bad idea. IE is absolutely braindead about dealing with illegal UTF-8 chars. It will accept just about any sequence of bytes as a valid UTF-8 char which causes all sorts of problems. I was talking about the common representation of an invalid sequence. That's the question mark sign you usually see in a browser when the encoding is incorrect. Yes, but it all comes down to how you do it. Say you have a 3 byte sequence that starts with 0xE0 (E0 indicates the start of a 3-byte utf-8 char) but the 3 bytes together don't actually make up a valid utf-8 char. Id you substitute those 3 bytes with a ? or some other character you have just created a nasty XSS vector for web apps. You don't substitute it with a ? or some other character, you replace it with U+FFFD (0xEF 0xBF 0xBD in UTF-8). I'd love to hear how that causes an attack vector. It doesn't matter what you replace it with. If the byte sequence is: 0xE0 And you replace those bytes with some other byte in this sort of context: input type=text name=foo value=0xE0 input type=text name=bar value=$data Now do your silly replacement: input type=text name=foo value=0xEF 0xBF 0xBD input type=text name=bar value=$data That now means that IE interprets the value attribute of the foo element as: value=0xEF 0xBF 0xBD input type=text name=bar value= And now $data is suddenly outside the quoted value attribute! Oops! Major XSS. Google Groups and Yahoo were both hit by this last year. Interesting. I assume that was a weakness in the respective implementation, right? Since 0xE0 should never be regarded a valid sequence since neither nor are in the range above 0x7F... This is (obviously) given to multiple intepretations. But when I suggested the feature, I mentioned for less stringent apps. Rasmus' case, the URL, should be more stringent and reject those which contained wholly invalid utf-8 sequences, for short sequences, overlong sequences and outright unmappable bytes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #43941
Stanislav Malyshev wrote: Hi! Are there any objections to incorporating bugfix for #43941 (fix for how json handles invalid UTF-8 sequences) into 5.2? I had some requests about it, right now it's only in 5.3+. Is there the alternative of substituting an unmappable character FFFD in place of the invalid sequence? This a a reasonable alternative behavior for some less stringent cases. (Yes, the fix is better than the status quo, but just taking this a step further). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] faster public domain MD5 implementation
Alexey Zakhlestin wrote: isn't public domain specific enough? Public Domain actually isn't a universal concept, and it isn't recognized everywhere in law. A very open BSD style license first, followed by granting it to the public domain, should cover all bases. Even somewhere that doesn't recognize public domain should fail over to accept your BSD license. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VS 2005 Support for 5.3?
Marcus Boerger wrote: Hello Andi, most struct sizes do not matter in the windows API (becasue it takes care of that). The problem actually lies in the POSIX stuff and the modified stuff as well as the new *_r() and *_l() and what not functions that do not exist in the older functions. A thing that hurts first is the memory allocation. Basically this boils down to that you have to bind statically and may not share any malloc block to get freed in the other code. Between VC6, 2002, 2003, 2005 I had various attempts of getting cross build libs/binaries work and never had real success (and don't ask why I tried it). It works very well for modules which are well-partitioned. E.g. if the same module frees all of it's own memory (as httpd will do through APR for all apr allocations) life is happy. When you pass results that the callee is intended to free() when they are finished with the data, things will explode. For example, mod_aspdotnet always needed to be compiled in a C++.NET managed app, and was susceptible to this sort of issue running on a VC6 build of the httpd library; but it never had a problem because it did all of the httpd-oriented allocations from apr_palloc calls. What will trip us all up is the fact that we all tightly bind to openssl in particular. That's a mess all it's own if compiled to a different CRT. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VS 2005 Support for 5.3?
Andi Gutmans wrote: Although it may work for you with your applications unless all of your 3rd party libs are compiled with VS 2005 there's a fair chance that you'll have issues when data structures are passed between PHP which is compiled against one CRT lib to DLLs which were compiled with older versions (different size of structures, etc...) Or more to the point, localized resources that actually exist in one CRT which aren't visible to the other CRT. Faux-posix I/O that MS implements is a really good example of this. If you are building to Apache httpd binaries /as shipped by the ASF/, you will want to ship these in VC6 for the lifespan of httpd 2.0/2.2. As the corner turns over to httpd 2.4 sometime soon, there's a good chance that VS2005 will be picked up at that point (and stay there for it's lifetime). I doubt ASF will pick up VS2008 quickly, given the number of clib issues that occur in each iteration of the libraries. One trouble is that AS still ships Perl built on VC6 runtime, Python on the VS2003 runtime, etc etc. Until everyone can land on VS2005 at the same approximate time, it's a game of cat and mouse. [We won't go into the lack of wisdom of MS shipping yet-another-clib for each of their compiler versions.] If you just clean up the .pdb's to the point that they import cleanly, you can really keep everyone happy, today and tomorrow. When you ditch the .pdb's, it's no longer possible to export .mak build files at all for use outside of the studio-world. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf and the generated configure script for PHP6 is faulty [the fix].
Hartmut Holzgraefe wrote: The complaints over the 4 or 5 I have mentioned on the list has borne the remarks that I swamp the list with the reports, how it would be if I dumped a couple hundred? if you dumped them on the list you would end up in everyones ignore list as *the list is not the right communication channel for that* Well, other than the totally uncivilized discussion by nearly everyone on this thread, I'd argue that discussing the whole you must use the one working (long abandoned) version of autoconf is certainly a good topic for a developer list and a good puzzle to solve. I'd have to agree with Dale on this point; PHP has more fragile dependencies on build tools than any modern open source project out there. I totally disagree with him that not providing binaries is discourteous to users; that's a packager problem (and on Mac/OSX, one to complain to Apple about, eh?) Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] POSIX regex
Rasmus Lerdorf wrote: Perhaps the real argument here is whether we should be doing Unicode at all? I've watched these debate with tremendous interest. i18n is one of my pure 'hobbies' (my 'clients' are all quite happy with ISO-8859-1, and one of my backgrounds is WinNT where everything became unicode within the OS.) I'm pondering if utf-8 as the 'default' encoding wouldn't have been a more effective approach than pure unicode wide-chars, but no matter how you slice this, there will be several points of pain in the transition. Rethinking in terms of utf-8 might be an interesting exercise, just to draw up a comparison of 'what is broken' when sliding between a PHP5 ISO charset and a PHP6 Unicode or utf-8 charset. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Stuck on PHP 4?
Vesselin Kenashkov wrote: -1 Because the majority of the installation (somebody two month ago in this list mentioned that php 5 has just 10% adoption) is still php4 just makes no sense to drop the support. This is a very old and tired argument, and pretty much is exactly where Apache httpd was, with respect to 1.3, at a similar timeframe. Folks find it to easy to stay with what they have installed. And even once 4.4 'ends', you will still have security patches (as mentioned) to keep them safe, if they even bother the patch/update. Adoption will be slow. But it doesn't justify leaving the developers dug in the sands trying to move changes back to 4.4. If they want the glitz, jazz and even the most up to date bug fixes, they'll have to come along for the ride. Take care of your *developers*, and your users will have a platform they can appreciate and enjoy. Focus on acting like a BigCo and you will sap the developers' time and energy. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] TSRMG
Stanislav Malyshev wrote: something isn't clear to me: Is php as apache module supposed to work without problems - if compiled as zts - only on apache worker or even on apache prefork? I think if you manage to compile it that way it might work, but I don't really see why you would want to do it - TS build is slower. If you want a module loadable under either prefork, or worker, or even perhaps the newer event mpm; you must build zts. Since many OS bundles support multiple MPM's - they are going to build zts. And you are right - wins you nothing (loses you a bit in performance) to run the prefork MPM with zts. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature(let) idea
Windows Explorer on WinXP does a fine job for me displaying binary version numbers, pulling up dll properties of .so files, etc. Not sure which issue you are seeing? Andi Gutmans wrote: Damn, I think you are right :) That's weird. There are some tools which only work with the .dll filename (i.e. Windows Explorer). Maybe my idea is better then :) Andi -Original Message- From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 10:53 PM To: Andi Gutmans Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Feature(let) idea Andi Gutmans wrote: I got a feature idea from Apache. Apache will automatically translate mod_rewrite.so in LoadModule to mod_rewrite.dll on Windows. It does? Apache/Win32 actually names the '.dll' as mod_rewrite.so on windows. There's nothing special about the '.dll' filename extension, a similar example is the .cpl control panel extensions, which are .dll's that are loaded into the system settings schema, .scr for screensaver dll's following that API, etc. In general, it's a good idea. My builds of php on win32 *are* entirely in the unix-style, for my customers who need to toggle between win32 and unix. It makes the documentation much simpler when you don't need two entirely different sets. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature(let) idea
Andi Gutmans wrote: I got a feature idea from Apache. Apache will automatically translate mod_rewrite.so in LoadModule to mod_rewrite.dll on Windows. It does? Apache/Win32 actually names the '.dll' as mod_rewrite.so on windows. There's nothing special about the '.dll' filename extension, a similar example is the .cpl control panel extensions, which are .dll's that are loaded into the system settings schema, .scr for screensaver dll's following that API, etc. In general, it's a good idea. My builds of php on win32 *are* entirely in the unix-style, for my customers who need to toggle between win32 and unix. It makes the documentation much simpler when you don't need two entirely different sets. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Toggling enable_dl API off for runtime?
In httpd server (and most) there is a startup phase, when we generally trust what the admin has done, and a runtime phase. There are obvious exploits if untrusted scripts can run arbitrary dlload's after startup. enable_dl in php.ini will obviously override this, but to start up and load dynamic extensions, it's initially required to be on. Is there any sense in having php4apache2 (and other SAPI's) permitted to run the entire startup phase of php prior to turning enable_dl back off for the runtime phase of the server? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Toggling enable_dl API off for runtime?
Rasmus Lerdorf wrote: William A. Rowe, Jr. wrote: In httpd server (and most) there is a startup phase, when we generally trust what the admin has done, and a runtime phase. There are obvious exploits if untrusted scripts can run arbitrary dlload's after startup. enable_dl in php.ini will obviously override this, but to start up and load dynamic extensions, it's initially required to be on. Is there any sense in having php4apache2 (and other SAPI's) permitted to run the entire startup phase of php prior to turning enable_dl back off for the runtime phase of the server? enable_dl only affects the userspace dl() function. That can only be called at the runtime phase, as you call it. So what you are proposing doesn't make much sense. Thank you for clarifying, Rasmus. Since userspace dl() can pollute future requests on the same prefork worker, or pollute other workers running on the threaded/worker style MPM, is there any thought to disabling this by default in at least one of the flavors of proposed php.ini solutions that are provided with the distribution? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Toggling enable_dl API off for runtime?
Rasmus Lerdorf wrote: William A. Rowe, Jr. wrote: An example php.ini file that is significantly immune to these side effects would seem to be a good idea. Either that, or a DON'T COHOST UNTRUSTED SCRIPTS disclaimer :) Disabling dl() is a rather well-known ISP configuration. And it isn't allowed at all in any threaded sapis, so that part isn't an issue. I guess you are asking us to provide an example .ini file for hosting companies. The sticky point here is that I think most of us would suggest using a fastcgi or a completely vm'ed setup for any sort of secure hosting. And in both those cases dl() wouldn't actually be a problem. I concur w.r.t. cgi, that's the gist of the response to bugtraq I'm drafting. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Toggling enable_dl API off for runtime?
Richard Lynch wrote: On Thu, May 31, 2007 3:36 pm, William A. Rowe, Jr. wrote: In httpd server (and most) there is a startup phase, when we generally trust what the admin has done, and a runtime phase. There are obvious exploits if untrusted scripts can run arbitrary dlload's after startup. Call me silly, but if you've got untrusted scripts running, dl or no dl, you are in a boat-load of trouble... We don't disagree :) But it seems many hosters are happy to do this for arbitrary people with a very low identity threshold. enable_dl in php.ini will obviously override this, but to start up and load dynamic extensions, it's initially required to be on. Is there any sense in having php4apache2 (and other SAPI's) permitted to run the entire startup phase of php prior to turning enable_dl back off for the runtime phase of the server? I still haven't figured out why dl() needs to go away at all, frankly. Why not default if off and add yet another php.ini flag, or add a special php.ini flag which does the exact same thing as putting dl on the list of banned functions. As Rasmus pointed out, there's no need for two flags. I'm not seeing the big win of killing dl... Nor I - you point out the right solution in your first paragraph. But given that people seem to do this, dl certainly allows a much more fine-grained abuse of httpd, IIS, etc in-process than the php language itself. /shrug Mostly responding to the dire sounding Apache httpd vulenrabilities bugtraq message id [EMAIL PROTECTED] which consisted of one real bug comingled with many silly claims. Thus the one year lack of response by httpd - trawling through his original pile of poop for the one diamond in his claims was more cycles than any of the security team could stand. For my future reference, running untrusted php scripts for end users is not a design consideration? Cohosted php scripts running on the same server instances / processes is not supported? My point is that once the process is poisoned by one vhost's php script, that same process is used again for another vhost. Obviously there are other posix_* api calls that might also be a concern, but unless the admin sets 'MaxRequestsPerChild 1' - the subsequent request is running in the environment of the prior request (and let's not even start with the worker / threaded side effects ;-) An example php.ini file that is significantly immune to these side effects would seem to be a good idea. Either that, or a DON'T COHOST UNTRUSTED SCRIPTS disclaimer :) Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] better changeset tracking
Stanislav Malyshev wrote: Switching to subversion would mean a learning curve for some, and a change of PHP development tools and practice for _everyone_ involved in php.net. It's a major step, particularly at a time when people are I used to think so, but my experience working with SVN on Framework shows it's not that different, at least on the level I use it (and that'd be the level most other people would use it I guess - checkout/update/diff/commit). So if we talking learning curve, it's not that different - svn up vs. cvs up :) I don't know though how (and if at all possible) to port karma system, changelog, etc. but that's admin stuff already. Would be nice if svn already had versioning for metadata, but otherwise it's not that hard to learn (there are even tricks to jump your live tree from a cvs checkout to an svn checkout, although a cvs diff/svn checkout and patch is usually simpler.) The ASF finally set a hard cutoff, and forced the hand. People adapted. In other works, svn doesn't suck :) It's just a slightly different tool. svn status is a huge improvement over cvs up to locate the diffs in your current checkout. svn 1.4 finally gives you the chance to mirror the repository. E.g. if you could do it in cvs, you can do it (somehow) finally in svn. The problem, as Rasmus points out, is that a huge repository like php's naturally doesn't migrate cleanly, and that's not even pointing out the nightmares of fat fingers crawling around rcs ,v files. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apache2handler/SIGSEGV with apache2 (prefork)
Antony Dovgal wrote: On 05/08/2007 04:02 PM, Oliver Block wrote: Am Dienstag, 8. Mai 2007 13:45 schrieben Sie: What was your configure line? ./configure --with-apxs2=/usr/sbin/apxs2 --prefix=/usr/local/php5 --enable-debug --enable-maintainer-zts --with-mysql --with-imap --with-imap-ssl There was a php4 rpm which was installed by the SuSE setup tool (YaST). After removing it, the server started without problems. So this segmentation fault seems to occur, when there are both versions, php4 and php5, installed. Ah, so you're compiling a threadsafe PHP to use with a non-threadsafe Apache and loading both PHP4 and PHP5 in the same time. This looks like a total misconfiguration. What non-threadsafe Apache? There are few such Apache 2 beasts. If apr was installed separately it's almost always going to pick up threads by default, and since these are YaST packages I'm betting dollars to donuts that apr comes from it's own rpm. Apache2 itself would therefore be threadsafe compiled against that apr. I'm gambling that PHP4 was non-zts and PHP5 was zts, resulting in mass confusion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine wrote: Andi Gutmans wrote: I see no value in making compatibility breaks in 5.x and not in the next major version. As it is we drive a lot of our users crazy. We already agreed this is a 6.x thing. IMHO one good reason to start a new branch for 5.x would be the ability to get rid off register_globals and magic_quotes in the 5 series without having to wait for PHP6 to come around. It seems to me that there are even more people around with their own agendas today. I don't think there are that many agendas, just more constituents of each. * admins who don't want binary compatibility breaks on subversion bumps, lest they start rebuilding all sorts of things beyond php itself. * admins and users who are sick of having things that 'just worked' broken even at a subversion bump, and who don't want to see anything deprecated until PHP6. * security folk who want frequently-abused features deprecated yesterday. * users who want the bleeding edge new toys and features. and -most importantly- * developers who want to implement new toys and push them out there to the admin and user communities tomorrow. Pride of authorship, usefulness, encouraging the health of the community, and all that. * developers who want to constrain growth so that the users have a more stable platform to use and they can follow all of the changes. They are most important because PHP -is- its developers. The only question, how to reconcile this most critical constituency with the other communities, such that all of the communities are mostly-happy. This probably only works if things don't get broken between 5.2.2 and 5.2.3, only absolutely manditory breakage occurs from 5.2 to 5.3, some wiggle room for cool new things is left open in 5.2.3 and 5.3, and finally that some of the more 'international' devs, users and admins work focus together on a 6.0 end-result, since they are the ones who needed the unicode implementation about five years ago. These are the same battles we all face at many projects (I'm hidden over at httpd, apr, etc etc) and the conclusion is usually the same. Pick a versioning policy, stick to it, and otherwise don't get in the way of dev's enthusiasm. [If any users/admins are insulted, mea culpa. Consider that there would be no PHP for you to use/admin without your dedicated developers. It's open source - if it broke, you still have both halves.] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failure
On Windows, there is no such thing as a true open-write-for-append.
Unlike Unix, write for append mode is not atomic, internally it is a
seek + write. Mix that with multiple writers, and you have an inherent
race condition built it.
Richard Quadling wrote:
That's good news. Has a patch been submitted? Even if it is initially
only a win32 compiler directive wrapping the lock?
On 14/04/07, Rob Richards [EMAIL PROTECTED] wrote:
I can sometimes reproduce the missing entries though never get data
corruption anymore.
This might now be a Windows only issue with how it is caching writes. I
did a little debugging and no errors occurred.
The file was opened successfully every time, the data was written
(correct number of bytes as well) every single time, but depending upon
the load on my system at the time it was a crap shoot whether every
single write actually made it into the physical file or not. Adding a
lock here did resolve it so that it worked 100% of the time.
Rob
Richard Quadling wrote:
So why are there missing entries?
I can even get the corruption back again if I use a shorter line (100
rather than 5000).
On 13/04/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
The new implementation does not use any locks, instead it uses direct
io, where locks are not necessary for append operations.
On 13-Apr-07, at 6:33 AM, Richard Quadling wrote:
On 05/04/07, Rob Richards [EMAIL PROTECTED] wrote:
No difference using sprintf()/fwrite() instead of fprintf().
I did come across a similar issue from apache:
http://mail-archives.apache.org/mod_mbox/httpd-dev/199503.mbox/%
[EMAIL PROTECTED]
Changing to use VCWD_OPEN_MODE, write() and close() seems to work.
Rob
Using PHP 5.2.2RC2-dev (cli) (built: Apr 13 2007 04:03:02) on
Windows with
for %x in (A B C D E F G H I J K L M N O P Q R S T U V W X Y Z) do
start php -r ini_set('error_log','/tmp/test.log');for($i=0;$i1000;
$i++)error_log(str_repeat('%x',5000));`;
And then doing some analysis of the log file I'm finding that not
all
the data has been written.
Array
(
[A] = 4965993
[B] = 4590918
[C] = 4525905
[D] = 4695939
[E] = 4495899
[F] = 4710942
[G] = 4495899
[H] = 4645929
[I] = 4540908
[J] = 4580916
[K] = 4535907
[L] = 4470894
[M] = 4480896
[N] = 4550910
[O] = 4610922
[P] = 4500900
[Q] = 4630926
[R] = 4480896
[S] = 4500900
[T] = 4535907
[U] = 4630926
[V] = 4470894
[W] = 4645929
[X] = 4825965
[Y] = 4845969
[Z] = 4920984
)
Lines (Should be 26 * 1000) : 23973
Longest (Should be 5024) : 5024
Shortest (Should be 5024) : 5024
Out of the 26,000 lines expected we are missing 2027 lines.
So no corruption of the lines, just missing ones.
The only explanation I can think of is that the locking is working,
but nothing is waiting for the lock to become available.
Richard.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?
c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failure
Richard Quadling wrote: So isn't locking the solution for Windows? If this is single writer process, even with multithreads - a mutex is most efficient, otherwise with concurrent writer processes, file locking makes the most sense. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] British Patch
Andrew Brampton wrote: As you can see this improvement makes PHP easier on the eye for all those loyal subjects of the crown. Given the value proposition of saving 96.7% stack and heap space per variable created, the patch looks worth considering. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.1 crashing Apache/IIS...
Thomas Hruska wrote: Heads up! Installed the latest Win32 binaries of thread-safe PHP 5.2.1 on Win32 Apache and IIS. PHP started crashing (definitely PHP - php5ts.dll) when I went to access the MyProBB web forum. (Win32 Apache flat out crashes, IIS bails with HTTP 500 errors). Considering PHP 5.2.1 was a security release with borked safe malloc code for threading, is there any chance of a 5.2.2 bugfix-only release to get good 'official' code into users' hands? No 5.2.2_RC1 in sight, but I'm pretty certain these fixes are already on PHP5.2 branch? Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS heads-up
Antony Dovgal wrote: On 02/23/2007 11:31 PM, William A. Rowe, Jr. wrote: FYI, a cvs rtag -d php5_5_0 might be in order before somebody trips over this (if 5.2 ever evolves to 5.5, sort of unlikely but who knows?) Was there ever such a release? There is such a tag hiding out there across php-src. (It's possibly hard to find because it's hiding in alot of the attic files, which is why I suggested rtag -d.) Unless, was there a purpose for tag (not branch) 5.5.0? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS heads-up
Antony Dovgal wrote: Probably somebody set this tag several years ago. Is this a problem? Of course, if you are the person who goes to tag php5_5_0, which will blow up loudly, or almost silently if none of the current files have that tag but they sit in the attic. cvs co will pick them up in the later case quite quietly, and if you aren't paying attention, are delivered in the final tarball :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS heads-up
Marcus Boerger wrote: Hello William, why? Simple cvs tag -F will do the trick. Nope - because -F doesn't remove tags, only overrides them. Ancient attic artifacts would remain tagged... Antony Dovgal wrote: Well, we're not going to use in anyway, because it doesn't comply with the naming standard we use: php_x_x_x, not phpx_x_x. Good point :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 4.4.6RC1
Derick Rethans wrote: Hello! there is a critical issues in PHP 4.4.5: - when register_globals = On, sessions don't work correctly (segfaults). Because of this I'd like to release a 4.4.6 soon with this fixes. As there is also an upgrade to pcre 7.0 we'd need atleast one RC, which I plan to release on Thursday. PCRE sounds like a destabilizing element, but if confidence is high(?) It would be nice to see a bugfix-only 4.4.x and 5.2.x release very soon, seeing the regressions that have been introduced after the RC phase has begun for the last few releases :) Speaking for joe user here (I patch around them). I have time to examine and run one RC per release here through the paces and not a whole lot more, and I'm pretty sure other testers are in the same place, so to keep adding destabilizing changes after the RC cycles begin - it sort of bites :) Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
Stefan Esser wrote: It should be noted, that the PHP Group is not allowed to give anyone the right to use PHP in it's product name. It's called a Trademark. It may or may not be a Registered Mark, but both concepts exist carrying varying weight in any jurisdiction. If they do so they violating the Open Source Definition http://www.opensource.org/docs/definition.php#5 Any kind of discrimination against anyone is not allowed. Giving some people special rights, like allowing them to use the name PHP in their Products name, while other parties are not allowed is clearly in violation with the discrimination paragraph... You are right. The PHP Group's grant of permission to use their Mark is not granted under the OSI model. Neither is any other Open Source project's grant. Your point is neither here nor there with respect of LICENSE TO THE CODE, which is what OSI's license compatibility applies to. Try creating GNUPHP or MicrosoftPHP - free or closed most projects treat their Marks protectively, and you would have hassles (legal or otherwise) with either using their Marks without their permission. No matter if it's stated in the license or not has little relation to Trademark law which has nothing to do with copyright law or patent law. None of the OSI licenses grant you permission to reuse their Mark for your purpose. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows build
Marcus Boerger wrote: Hello Ilia, weel 2002 aka 7.0 or 2003 aka 7.1 are pretty fine. We have left behind 6.0 long ago :-) For reference, ActiveState python is built on Studio 2003 al la 7.1, while their perl is still built VC 6, if you are looking to coexist more peacefully with one or the other. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows build
Edin Kadribasic wrote: Hi Andi, Turns out the problem is that Apache is building their binaries using VC6 so wrong CRT gets loaded. The only solution I found was to tell Windows to load Apache with msvcr80.dll instead of msvcr.dll by suppling a manifest file in Apache bin directory. If you crate Apache.exe.manifest that contains: ?xml version='1.0' encoding='UTF-8' standalone='yes'? assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0' dependency dependentAssembly assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' / /dependentAssembly /dependency /assembly The Apache will load PHP and PHP will be able to load extensions. It probably isn't good idea to force a different C Runtime on Apache like this. FYI - If Apache adopted this convention, it would break on systems without the VC80 CRT - but worse... VC80 carries the baggage of installing WinSXS (side by side assemblies) for anything pre-XP. There are Apache VC80 binaries generated by others. But because Apache means to interoperate (for today) with ActivePerl/ActivePython, we weren't prepared to mess around any further with the breadth of bogosity that VC8 introduces. Apache's actively picking it up for source code builders, as I suggested in an earlier posting. From the ASF's perspective - folks exploring the Source is always the primary mission of the foundation. Will Apache bump to VC 7.1 or 8.0 with Apache 2.4? Who knows. But Apache 2.0 (as distributed) is legacy - it will never veer into VC7+ territory. And Apache 2.2 already shipped with VC6, so it's unlikely to change, as well. Mitigate binary compatibility breakage is the buzzword once an even-minor version has shipped. (Odd-minor's e.g. 2.3 are a moving target/development branch - no hassle there of disrupting users). A last interesting question; what sort of headaches have you hit loading within the ISAPI/IIS environment? I would presume that older/modern IIS flavors suffer from similar headaches? I do hang around here, so will be very curious to keep on top of the PHP project's progress w.r.t. Studio 2005. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows build
This sounds like a sane approach. My own 2c is that your failure to load represents a failure to correctly package the .manifest data of the individual modules; perhaps this is due to the individual modules requiring an entry for php5ts.dll? Without digging deeper, it is probably most sane to ship vc 6 (or vc 7.1) binaries for now. But I'd strongly encourage research into vc 8, not for binary distribution, but because the MS Visual Studio 2005 Express Edition (available free) is your end users' most approachable platform for exploring and compiling the sources, without the cost of other VC compilers and without the stress of fighting with the hassles of the other open compiler alternatives. Ilia Alshanetsky wrote: Edin, Thanks for the detailed analysis and spending time analyzing the issue. Based on what you've said I think our best option is to go back to VC++ 6.0 for this release, we are too far along in the release cycle to experiment with things. Perhaps for the next release we can revisit the issue, assuming there an interest and a benefit of using VC++ 8.0 can be quantified. On 5-Jan-07, at 10:48 PM, Edin Kadribasic wrote: I looked around at other projects and everyone seems to be using VC++ 6.0 for their builds (Active state, apache, ...) which eliminates all the hassle with bundling C runtime, etc. So I think the best thing for us would be to stick to the good old C compiler for making the Windows distro. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows build
Edin Kadribasic wrote: I can get PHP to work fine on the command line, both cgi and cli. It also works fine under IIS using fastcgi. But loading sapi dll into a webserver (not using php.exe or php-cgi.exe) works for the sapi itself, but trying to load any extensions via php.ini fails miserably. Sometimes you will get an error that the C runtime was attempted to be loaded in an illegal way, sometime PHP will claim that the extension does not exist, etc. Questions; This is WinXP SP2 fully updated? (E.g. all security 'fixes' snuck in?) Extensions are located in the same directory as php5ts.dll itself? The webservers you are testing with use the same msvcr as the php build? (Depends.exe in the psdk or vc product is wonderful for inspecting this.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dumping support for Windows 98 and Windows ME
Andi Gutmans wrote: In the spirit of dumping Win95 support in PHP 5, I'd like to officialy dump Windows 98ME support from this point onwards. We are sticking to old Windows APIs because of this support which doesn't make much sense considering that Microsoft has stopped supporting those platforms six months ago (http://www.microsoft.com/windows/support/endofsupport.mspx). So I see no reason for us to support Micorsoft customers better than they do :) Those who are stuck on those versions should just stick to the versions up to PHP 5.2.0. They are not getting Windows updates, so why should they get PHP updates? As the prime win32 mover at httpd, I'd say I wholeheartedly agree. APR, the portability layer, is moving in this same direction. THAT SAID... please be prepared for hoots and howls, you will be surprised to discover how many Win98SE boxes keep going, and going, and going. Because there are better free/open operating systems solutions out there, over win32, I no longer hold the opinion that 'forcing' a minimum baseline of WinNT 4 SP6 or WinNT 5 (2000) is terribly unreasonable. Let those who haven't/won't upgrade, due to cost, seek out a better solution. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_compile.c
Ilia Alshanetsky wrote: On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote: Hello Ilia, also an ISO/shared server will never be securewhatever you do and you can make MySQL disaalow external connections. That basically means in those scenarios you do not need any authentication at all and thus get better speed as in more responses. Now is that bad? It is not, the only idea is that while your servers maybe secure, however you may not entirely trust your datacenter, so encryption of the data would protect you against man-in-the-middle attacks. This isn't philosophical, privacy regulations in many industries now mandate all tiered solutions use encryption between every network attached box, no matter if it's hiding behind the DMZ or not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upload progress
Arpad Ray wrote: If you set post_max_size to 0, you can parse the post data yourself from php://input. Combine that with the Content-Length value from apache_request_headers() and you have everything you need for a progress monitor. Of course - this is entirely irrelevant if the client uses Transfer-Encoding: chunked, in which case you better ignore Content-Length if the client (or middle proxies) provided one. And if you don't grok this, you'd better search for the Watchfire Report on HTTP Request / Response Spoofing vulnerabilities before creating yet another vulnerable server app. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: Fw: [PHP-DEV] New Installer for PHP 5.2
Given that there is significant interest, and no objection, I'll commit this later today. Are any of trunk / 5.2 or 4.4 branches frozen right now? Bill Steph Fox wrote: Steph Fox wrote: It wouldn't make any difference to John, since he'd need to support older Apache installs for the installer anyway... apart from that, it's got my vote! Sure it would. PHPIniDir is apache directive provided by php's sapi/apache2*. Adding it to sapi/apache would make it universally available to PHP installer. Sometimes I need THREE cups of coffee before I start typing :) You're right of course. Ilia, would it be ok to commit the backport of the patch? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Fwd: Fw: [PHP-DEV] New Installer for PHP 5.2
John Mertic wrote: Hi there, On 7/26/06, Steph Fox [EMAIL PROTECTED] wrote: In the case of Apache 1 only, php-apache.ini needs to be in the toplevel Apache directory. In every other case (php-cli.ini, php-cgi-fcgi.ini php-apache2.ini, and php-whatever-2.2-SAPI-is-called.ini) it needs to be in the PHP install dir. That means the only chance of having a meaningful collision with an existing PHP installation is via the Apache 1 module, thanks to the placement of that .ini file. I've never that noticed back when I was running Apache 1; would having the php.ini in the Windows PATH or setting PHPRC help this any? I've offered this patch before to provide the PHPIniDir for the Apache 1.3 SAPI - no response. Are people interested in my reintroducing it? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: wrowe
apache and apache2 sapi build fixes for obscure platforms (aix, hpux etc.) and to tend the long neglected php5apache2filter streaming sapi module. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Help with generating a stack trace on IIS6
Hannes Magnusson wrote: Hi Sharad I would appreciate if anyone can help me in finding out how to obtain extra information from php ... I am not able to find a debug pack for PHP 4 The sad bit is, it's totally unnecessary to have a specific debug build, but the maintainers have never taken advantage of the fact. Leave /O options alone in the release build (optimize to your hearts' content), leave /MD for the run time, but compile with the /Zi flag (ensuring the sources don't clash with the output binary name, or else use /Fdothername to compile the sources with a different .pdb filename to avoid a collision), and finally link /debug /opt:ref. The result is the -same- .dll or .exe as the original release style, but an -external- .pdb matching the binary - which Dr. Watson or any other windows debugger can use and spit out backtraces. Windows Apache HTTP Server releases offer this; the corresponding .pdb's are zipped up in their very own package. Normally they don't help a user. But if the user is crashing, unzipping the .pdb files that correspond to their release provides all the backtrace info required. In fact, with the binaries + pdb's - the user.dmp crash file can be ripped open on a dev box which has the appropriate debugging tools, just like using an non-stripped unix binary with gdb. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Repository Corruption
Two weeks ago; ext/pcre/config0.m4 was added by duplicating ext/pcre/config.m4,v directly in the CVS repository. Unfortunately this breaks every historical checkout, due to the now duplicate existance of config0.m4 and config.m4, causing duplicate builds of the pcre extention. Of course, if one wants to do this in order to preserve history, it's still essential to remove all prior tags from the new ,v file - to avoid exactly this sort of duplicate checkout -by tag-. Of course checkouts by date would still check out duplicate files. And of course nobody wants the true history concealed by removing the old, now removed file from Attic/. So the patch to the true config0.m4,v is attached for someone to modify this directly in cvs. Note this is specific to today's untagged state, and within days this patch would become invalid when config0.m4,v is tagged with new, non- config.m4,v tags. Bill --- config0.m4,v-orig 2005-12-07 00:53:37.0 -0800 +++ config0.m4,v 2005-12-07 00:54:08.0 -0800 @@ -1,219 +1,6 @@ head 1.38; access; -symbols - php_5_1_1:1.36.2.1 - php_5_1_0:1.36.2.1 - php_4_4_2RC1:1.29.2.7.2.1 - php_5_1_0RC6:1.36.2.1 - php_5_1_0RC5:1.36 - php_5_1_0RC4:1.36 - php_4_4_1:1.29.2.7.2.1 - php_5_1_0RC3:1.36 - php_5_1_0RC2:1.36 - php_4_4_1RC1:1.29.2.7.2.1 - PRE_NEW_OCI8_EXTENSION:1.36 - php_5_1_0RC2_PRE:1.36 - php_5_0_5:1.32.2.2 - php_5_0_5RC2:1.32.2.2 - php_5_0_5RC1:1.32.2.1 - php_5_1_0RC1:1.36 - BEFORE_UNICODE_MERGE:1.36 - PHP_5_1:1.36.0.2 - php_5_1_0b3:1.35 - php_4_4_0:1.29.2.7 - php_4_4_0RC2:1.29.2.7 - php_5_1_0b2:1.35 - php_4_4_0RC1:1.29.2.7 - php_5_1_0b1:1.35 - PHP_4_4:1.29.2.7.0.2 - php_5_0_4:1.32 - php_4_3_11:1.29.2.5 - php_5_0_4RC2:1.32 - php_4_3_11RC2:1.29.2.5 - php_4_3_11RC1:1.29.2.5 - php_5_0_4RC1:1.32 - php_5_0_3:1.32 - php_4_3_10:1.29.2.5 - php_5_0_3RC2:1.32 - php_4_3_10RC2:1.29.2.5 - php_5_0_3RC1:1.32 - php_4_3_10RC1:1.29.2.5 - PRE_NEW_VM_GEN_PATCH:1.32 - php_5_0_2:1.32 - php_4_3_9:1.29.2.5 - php_5_0_2RC1:1.32 - php_4_3_9RC3:1.29.2.5 - php_4_3_9RC2:1.29.2.5 - php_5_0_1:1.32 - php_5_0_1RC2:1.32 - php_4_3_9RC1:1.29.2.5 - php_5_0_1RC1:1.32 - PHP_5_0:1.32.0.2 - php_5_0_0:1.32 - php_4_3_8:1.29.2.5 - PHP_4_3_7:1.29.2.5.0.2 - php_5_0_0RC4:1.32 - php_5_0_0RC3:1.32 - php_5_0_0RC3RC2:1.32 - php_4_3_7:1.29.2.5 - php_5_0_0RC3RC1:1.32 - php_4_3_7RC1:1.29.2.5 - php_5_0_0RC2:1.32 - php_5_0_0RC2RC2:1.32 - php_4_3_6:1.29.2.5 - php_5_0_0RC2RC1:1.32 - php_4_3_6RC3:1.29.2.5 - php_4_3_6RC2:1.29.2.5 - php_4_3_6RC1:1.29.2.5 - php_4_3_5:1.29.2.5 - php_4_3_5RC4:1.29.2.5 - php_5_0_0RC1:1.32 - php_5_0_0RC1RC2:1.32 - php_5_0_0RC1RC1:1.32 - php_4_3_5RC3:1.29.2.5 - php_5_0_0b4:1.32 - php_5_0_0b4RC1:1.32 - php_4_3_5RC2:1.29.2.5 - php_4_3_5RC1:1.29.2.5 - php_5_0_0b3:1.32 - php_5_0_0b3RC2:1.32 - php_5_0_0b3RC1:1.32 - php_4_3_4:1.29.2.3 - php_5_0_0b2:1.32 - php_4_3_4RC3:1.29.2.3 - php_5_0_0b2RC1:1.32 - php_4_3_4RC2:1.29.2.3 - php_4_3_4RC1:1.29.2.3 - php_4_3_3:1.29.2.3 - php_4_3_3RC4:1.29.2.3 - php_4_3_3RC3:1.29.2.3 - BEFORE_ARG_INFO:1.32 - php_4_3_3RC2:1.29.2.3 - php_5_0_0b1:1.32 - php_4_3_3RC1:1.29.2.1 - BEFORE_FD_REAPPLY:1.29.2.1 - php_4_3_2:1.29.2.1 - PHP_4_3_2:1.29.2.1.0.2 - php_4_3_2RC4:1.29.2.1 - BEFORE_FD_REVERT:1.29.2.1 - php_4_3_2RC3:1.29.2.1 - php_4_3_2RC2:1.29.2.1 - php_4_3_2RC1:1.29.2.1 - php_4_3_1:1.29 - PHP_4_3_1:1.29.0.8 - PHP_4_3_0:1.29.0.6 - PHP_5_0_dev_before_13561_fix:1.29 - PHP_4_3_before_13561_fix:1.29 - PHP_4:1.29.2.1.0.6 - php_4_3_0:1.29 - php_4_3_0RC4:1.29 - php_4_3_0RC3:1.29 - php_4_3_0RC2:1.29 - php_4_3_0RC1:1.29 - PHP_4_3:1.29.0.2 - php_4_3_0pre2:1.29 - php_4_3_0pre1:1.28 - php_4_3_0_dev_zend2_alpha3:1.28 - php_4_2_3:1.26.2.1 - php_4_2_3RC2:1.26.2.1 - new_apache_hooks:1.28.0.2 - php_4_2_3RC1:1.26.2.1 - dev/:1.28 - php_4_2_2:1.26 - PHP_4_2_2:1.26.0.4 - php_4_3_0_dev_zend2_alpha2:1.27 - php5_5_0:1.27 - php_4_3_0dev:1.27 - php_4_3_0_dev_zend2_alpha1:1.27 - php_4_2_1:1.26 - php_4_2_1RC2:1.26 - php_4_2_1RC1:1.26 - php_4_2_0:1.26 - php_4_2_0RC4:1.26 - php_4_2_0RC3:1.26 - php_4_2_0RC2:1.26 - php_4_2_0RC1:1.26 - PHP_4_2_0:1.26.0.2 - php_4_1_2:1.25 - php_4_1_1:1.25 - ChangeLog:1.26 - php_4_1_0:1.25 - php_4_1_0RC5:1.25 - php_4_1_0RC4:1.25 - php_4_1_0RC3:1.25 - php_4_1_0RC2:1.25 - php_4_1_0RC1:1.25 - php_4_0_7RC3:1.25 - php4:1.25 - POST_SUBST_Z_MACROS:1.25 - PRE_SUBST_Z_MACROS:1.25 - php_4_0_7RC2:1.25 - php_4_0_7RC1:1.25 - PHP_4_0_7:1.25.0.2 - PRE_TSRM_MERGE_PATCH:1.25 - php_4_0_6:1.23 - php_4_0_6RC4:1.23 - php_4_0_6RC3:1.23 - php_4_0_6RC2:1.23 - php_4_0_6RC1:1.23 - PHP_4_0_6:1.23.0.2 - php_4_0_5:1.22 - php_4_0_5RC8:1.22 - php_4_0_5RC7:1.22 - php_4_0_5RC6:1.22 - php_4_0_5RC5:1.22 - php_4_0_5RC4:1.22 - php_4_0_5RC3:1.22 - php_4_0_5RC2:1.22 - php_4_0_5RC1:1.22 - PHP_4_0_5:1.22.0.2 - php_4_0_4pl1:1.20 - php_4_0_4pl1RC2:1.20 - php_4_0_4pl1RC1:1.20 - php_4_0_4REL:1.20 - php_4_0_4RC6:1.20 - php_4_0_4RC5:1.20 - php_4_0_4RC4:1.20 - php_4_0_4RC3:1.20 - php_4_0_4:1.20.0.2 - php_4_0_3:1.20 - php_4_0_3RC2:1.20 - php_4_0_3RC1:1.20 - php_4_0_2:1.20 - php_4_0_2RC1:1.20 -
Re: [PHP-DEV] CVS Repository Corruption
Jani Taskinen wrote: Not that we will patch the repository files, but why do you care? You actually use some old release branch? :) In case I wasn't clear, or the patch wasn't clear, this is -every- historical checkout that's broken. Including those in the past month. If you're comfortable patching the file, feel free. I don't care as long as it won't break HEAD or PHP_5_1 branches. ROFL - now that's funny! Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Repository Corruption
Rasmus Lerdorf wrote: Marcus Boerger wrote: the solution is correct. And btw just another reason to switch to svn. Without the patch the old branches magically inherit the new file just as we could change the past. I have applied the patch. Thanks Rasmus, and Marcus for your analysis. SVN has its own set of problems. Especially with respect to importing your CVS history - these various tweaks to CVS can burn the importer, it will be quite a chore to indentify those subtly corrupt ,v files, tweak them, and ensure the resulting repository is golden. However SVN has one distinct advantage, and that's when you are reorganizing. Renaming files -and directories- is painless, and history is preserved. Not that I'm advocating either way. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.1.0 - sha256() and sha256_file() support
Sara Golemon wrote: with MD5 and SHA1 more or less broken Overstatement much? I've had implementations of sha256,384, and 512 lying about for months now (possibly over a year), but was told they didn't have a place in core since mhash provided the functionality (A statement I recall agreeing with at the time fwiw). What changed? One consideration, if one wanted to deploy PHP in a FIPS compliant manner, is that reimplementations of these algorithms is not acceptable. One clean solution if linked against OpenSSL is to dispatch sha256/384/512 to those certified algorithms. But in any case, all three certainly make sense. Adding sha256 alone sure seems like a false start. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Comment on Bug #30153: FATAL erealloc() error whenusinggzinflate()
Perhaps this is a stupid question, but has anyone ensured that zlib rev 1.2.3 still exhibits this behavior? The trouble ticket is close to useless for recapping this; but I'm happy to shepard a fix or some solution through the zlib dev team. The ticket indiciated that PHP is using it's own fork of zlib, perhaps I'm confused on the issue, though. All versions pre-1.1.4 and pre-1.2.3 are known-vulnerable, so there's really no point in reproducing these problems on anything other than the current rev 1.2.3. Bill Ron Korving wrote: My bad, I remembered the initial post wrong. Still, the primary bug report should be for the zlib fellas. They're the ones who need to fix their lib. Secondary, maybe php folks can see if the problem can be worked around. But still, the guys with the real problem are the zlib guys. Have you filed a bugreport there? That should be the primary action in this situation. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] building HEAD on windows
Rob Richards wrote: Attached is a patch to allow PHP 6 to build on windows (ext/string/string.c). MS compiler doesnt allow arithmetic operations on void *. FYI arithmetic ops should never behave on (void *) since the sizeof(*(void*)) is, by definition, undefined. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 php4ts.dll 875k Larger in 5.1?
At 01:26 AM 6/28/2005, Andrey Hristov wrote: Should it be named php4ts? ewww - certainly not. Win32 has no problem with loading two modules, e.g. php4ts and php5ts, mod_php4 and mod_php5 all in the same process. But not if the dll names collide. At 09:56 AM 6/28/2005, Wez Furlong wrote: If there are overlaps between the compiled bases, then the loader can relocate DLLs until it figures out the best way to fit them all into the address space. This step becomes more expensive and more likely to occur as the quantity of DLLs used by a process increases. Yup. The most effective solution is to use the rebase command to generate a base address list, and in the linker command, use the construct /base:baseref.lst,modname which will drop everything in expected locations. All flavors of apr and apache use this. Almost 1mb sure sounds like a candidate for unbundling from the core. Bill -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] PHPIniDir for 1.3?
[Ping] Anyone interested in PHPIniDir Apache 1.3 directive support?
Bill
Several of my administrators have grown to love PHPIniDir
in the sapi/apache2handler/, so I've thrown together this
patch for Apache 1.3 mod_php to provide the feature. I'm
guessing alot of users would be grateful for it if they
want to keep php.ini in the conf/ tree, or wherever makes
the most sense for their system config.
Can be applied to mod_php4.c or mod_php5.c below;
--- sapi/apache/mod_php4.c
+++ sapi/apache/mod_php4.c
@@ -814,6 +814,18 @@
}
/* }}} */
+/* {{{ php_apache_phpini_set
+ */
+static const char *php_apache_phpini_set(cmd_parms *cmd, void *mconfig, const
char *arg)
+{
+ if (apache_sapi_module.php_ini_path_override) {
+ return Only first PHPINIDir directive honored per
configuration tree - subsequent ones ignored;
+ }
+ apache_sapi_module.php_ini_path_override =
ap_server_root_relative(cmd-pool, arg);
+ return NULL;
+}
+/* }}} */
+
/* {{{ int php_xbithack_handler(request_rec * r)
*/
static int php_xbithack_handler(request_rec * r)
@@ -918,6 +930,7 @@
{php_flag,php_apache_flag_handler, NULL, OR_OPTIONS,
TAKE2, PHP Flag Modifier},
{php_admin_value, php_apache_admin_value_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Value Modifier (Admin)},
{php_admin_flag, php_apache_admin_flag_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Flag Modifier (Admin)},
+ {PHPINIDir, php_apache_phpini_set, NULL, RSRC_CONF, TAKE1,
Directory containing the php.ini file (Admin)},
{NULL}
};
/* }}} */
--- sapi/apache/mod_php5.c
+++ sapi/apache/mod_php5.c
@@ -814,6 +814,18 @@
}
/* }}} */
+/* {{{ php_apache_phpini_set
+ */
+static const char *php_apache_phpini_set(cmd_parms *cmd, void *mconfig, const
char *arg)
+{
+ if (apache_sapi_module.php_ini_path_override) {
+ return Only first PHPINIDir directive honored per
configuration tree - subsequent ones ignored;
+ }
+ apache_sapi_module.php_ini_path_override =
ap_server_root_relative(cmd-pool, arg);
+ return NULL;
+}
+/* }}} */
+
/* {{{ int php_xbithack_handler(request_rec * r)
*/
static int php_xbithack_handler(request_rec * r)
@@ -918,6 +930,7 @@
{php_flag,php_apache_flag_handler, NULL, OR_OPTIONS,
TAKE2, PHP Flag Modifier},
{php_admin_value, php_apache_admin_value_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Value Modifier (Admin)},
{php_admin_flag, php_apache_admin_flag_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Flag Modifier (Admin)},
+ {PHPINIDir, php_apache_phpini_set, NULL, RSRC_CONF, TAKE1,
Directory containing the php.ini file (Admin)},
{NULL}
};
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] PHPIniDir for 1.3?
Several of my administrators have grown to love PHPIniDir
in the sapi/apache2handler/, so I've thrown together this
patch for Apache 1.3 mod_php to provide the feature. I'm
guessing alot of users would be grateful for it if they
want to keep php.ini in the conf/ tree, or wherever makes
the most sense for their system config.
Can be applied to mod_php4.c or mod_php5.c below;
--- sapi/apache/mod_php4.c
+++ sapi/apache/mod_php4.c
@@ -814,6 +814,18 @@
}
/* }}} */
+/* {{{ php_apache_phpini_set
+ */
+static const char *php_apache_phpini_set(cmd_parms *cmd, void *mconfig, const
char *arg)
+{
+ if (apache_sapi_module.php_ini_path_override) {
+ return Only first PHPINIDir directive honored per
configuration tree - subsequent ones ignored;
+ }
+ apache_sapi_module.php_ini_path_override =
ap_server_root_relative(cmd-pool, arg);
+ return NULL;
+}
+/* }}} */
+
/* {{{ int php_xbithack_handler(request_rec * r)
*/
static int php_xbithack_handler(request_rec * r)
@@ -918,6 +930,7 @@
{php_flag,php_apache_flag_handler, NULL, OR_OPTIONS,
TAKE2, PHP Flag Modifier},
{php_admin_value, php_apache_admin_value_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Value Modifier (Admin)},
{php_admin_flag, php_apache_admin_flag_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Flag Modifier (Admin)},
+ {PHPINIDir, php_apache_phpini_set, NULL, RSRC_CONF, TAKE1,
Directory containing the php.ini file (Admin)},
{NULL}
};
/* }}} */
--- sapi/apache/mod_php5.c
+++ sapi/apache/mod_php5.c
@@ -814,6 +814,18 @@
}
/* }}} */
+/* {{{ php_apache_phpini_set
+ */
+static const char *php_apache_phpini_set(cmd_parms *cmd, void *mconfig, const
char *arg)
+{
+ if (apache_sapi_module.php_ini_path_override) {
+ return Only first PHPINIDir directive honored per
configuration tree - subsequent ones ignored;
+ }
+ apache_sapi_module.php_ini_path_override =
ap_server_root_relative(cmd-pool, arg);
+ return NULL;
+}
+/* }}} */
+
/* {{{ int php_xbithack_handler(request_rec * r)
*/
static int php_xbithack_handler(request_rec * r)
@@ -918,6 +930,7 @@
{php_flag,php_apache_flag_handler, NULL, OR_OPTIONS,
TAKE2, PHP Flag Modifier},
{php_admin_value, php_apache_admin_value_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Value Modifier (Admin)},
{php_admin_flag, php_apache_admin_flag_handler, NULL,
ACCESS_CONF|RSRC_CONF, TAKE2, PHP Flag Modifier (Admin)},
+ {PHPINIDir, php_apache_phpini_set, NULL, RSRC_CONF, TAKE1,
Directory containing the php.ini file (Admin)},
{NULL}
};
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
