[PHP-DEV] Re: Change of cgi behaviour in 4.3.0
On Wed, 25 Sep 2002, Edin Kadribasic wrote: For some reason http status reporting has been changed in the current CVS version of PHP. This breaks PHP under IIS and possibly other servers. Please see http://bugs.php.net/bug.php?id=19207 for details. The reason is that it did not work properly with Apache before. When seeing a status line in RFC 2616 format from a CGI, Apache will issue a 505 error, because Apache expects it to be in the informal CGI RFC format. Note that this specific change was requested after I improved the SAPI layer to always send out the status line. If a user had called header() to set the status code, the error would have been the same, regardless of the SAPI layer change. If IIS cannot accept the CGI RFC format, a configuration option needs to be added which chooses one of the formats. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Change of cgi behaviour in 4.3.0
On Wed, 25 Sep 2002 08:36:42 +0200 (CEST), Sascha Schumann wrote: On Wed, 25 Sep 2002, Edin Kadribasic wrote: For some reason http status reporting has been changed in the current CVS version of PHP. This breaks PHP under IIS and possibly other servers. Please see http://bugs.php.net/bug.php?id=19207 for details. The reason is that it did not work properly with Apache before. When seeing a status line in RFC 2616 format from a CGI, Apache will issue a 505 error, because Apache expects it to be in the informal CGI RFC format. Note that this specific change was requested after I improved the SAPI layer to always send out the status line. If a user had called header() to set the status code, the error would have been the same, regardless of the SAPI layer change. If IIS cannot accept the CGI RFC format, a configuration option needs to be added which chooses one of the formats. This is probably the best solution to the problem. We just have to remember to explain the issue in the release notes when 4.3.0 gets released. Perhaps also make the old format default on Windows since probably most people use php-cgi with IIS. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Change of cgi behaviour in 4.3.0
Just to clear any doubts - was there any real-world problem with the way things were working before this change? Zeev At 10:26 25/09/2002, Edin Kadribasic wrote: On Wed, 25 Sep 2002 08:36:42 +0200 (CEST), Sascha Schumann wrote: On Wed, 25 Sep 2002, Edin Kadribasic wrote: For some reason http status reporting has been changed in the current CVS version of PHP. This breaks PHP under IIS and possibly other servers. Please see http://bugs.php.net/bug.php?id=19207 for details. The reason is that it did not work properly with Apache before. When seeing a status line in RFC 2616 format from a CGI, Apache will issue a 505 error, because Apache expects it to be in the informal CGI RFC format. Note that this specific change was requested after I improved the SAPI layer to always send out the status line. If a user had called header() to set the status code, the error would have been the same, regardless of the SAPI layer change. If IIS cannot accept the CGI RFC format, a configuration option needs to be added which chooses one of the formats. This is probably the best solution to the problem. We just have to remember to explain the issue in the release notes when 4.3.0 gets released. Perhaps also make the old format default on Windows since probably most people use php-cgi with IIS. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Change of cgi behaviour in 4.3.0
This is probably the best solution to the problem. We just have to remember to explain the issue in the release notes when 4.3.0 gets released. Perhaps also make the old format default on Windows since probably most people use php-cgi with IIS. Well, I am not so certain about that -- lots of people start out with the simplest solution. That is CGI and a free web server such as Apache on the platform they are familiar with (e.g. Windows). Do we have any volunteers for adding the option to the CGI SAPI? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Change of cgi behaviour in 4.3.0
On Wed, 25 Sep 2002, Zeev Suraski wrote: Just to clear any doubts - was there any real-world problem with the way things were working before this change? Yes, there was a problem. I remember 'fixing' that, and there is also a bugreport about it which I can not find right now. Derick x= At 10:26 25/09/2002, Edin Kadribasic wrote: On Wed, 25 Sep 2002 08:36:42 +0200 (CEST), Sascha Schumann wrote: On Wed, 25 Sep 2002, Edin Kadribasic wrote: For some reason http status reporting has been changed in the current CVS version of PHP. This breaks PHP under IIS and possibly other servers. Please see http://bugs.php.net/bug.php?id=19207 for details. The reason is that it did not work properly with Apache before. When seeing a status line in RFC 2616 format from a CGI, Apache will issue a 505 error, because Apache expects it to be in the informal CGI RFC format. Note that this specific change was requested after I improved the SAPI layer to always send out the status line. If a user had called header() to set the status code, the error would have been the same, regardless of the SAPI layer change. If IIS cannot accept the CGI RFC format, a configuration option needs to be added which chooses one of the formats. This is probably the best solution to the problem. We just have to remember to explain the issue in the release notes when 4.3.0 gets released. Perhaps also make the old format default on Windows since probably most people use php-cgi with IIS. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Change of cgi behaviour in 4.3.0
Ok, we need to make sure we're not creating a bigger problem with that fix. Zeev At 10:44 25/09/2002, [EMAIL PROTECTED] wrote: On Wed, 25 Sep 2002, Zeev Suraski wrote: Just to clear any doubts - was there any real-world problem with the way things were working before this change? Yes, there was a problem. I remember 'fixing' that, and there is also a bugreport about it which I can not find right now. Derick x= At 10:26 25/09/2002, Edin Kadribasic wrote: On Wed, 25 Sep 2002 08:36:42 +0200 (CEST), Sascha Schumann wrote: On Wed, 25 Sep 2002, Edin Kadribasic wrote: For some reason http status reporting has been changed in the current CVS version of PHP. This breaks PHP under IIS and possibly other servers. Please see http://bugs.php.net/bug.php?id=19207 for details. The reason is that it did not work properly with Apache before. When seeing a status line in RFC 2616 format from a CGI, Apache will issue a 505 error, because Apache expects it to be in the informal CGI RFC format. Note that this specific change was requested after I improved the SAPI layer to always send out the status line. If a user had called header() to set the status code, the error would have been the same, regardless of the SAPI layer change. If IIS cannot accept the CGI RFC format, a configuration option needs to be added which chooses one of the formats. This is probably the best solution to the problem. We just have to remember to explain the issue in the release notes when 4.3.0 gets released. Perhaps also make the old format default on Windows since probably most people use php-cgi with IIS. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Interesting note
Hi, regarding to documentation of mysql_query() : [snip] Note: The query string should not end with a semicolon. [/snip] Is this mySQL problem or what? As far as I see in the sources this does not anything with PHP. So is it mysql issue. Thanks, Andrey -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Interesting note
On Wed, 25 Sep 2002, Andrey Hristov wrote: Hi, regarding to documentation of mysql_query() : [snip] Note: The query string should not end with a semicolon. [/snip] Is this mySQL problem or what? As far as I see in the sources this does not anything with PHP. So is it mysql issue. Yup, the MySQL API functions expect a string as query, without that semi-colon. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: broken stat cache?
On 09/25/02, Yasuo Ohgaki [EMAIL PROTECTED] wrote: It seems stat cache is broken. Just point it out the problem I noticed, since Wez is going to rewrite stat related code soon(?) IIRC. I re-routed the user-space stat() through the wrappers subsystem (a while ago), but didn't want/need to touch the stat and statcache code as it looked hairy; it wasn't broken, so I didn't fix it :-) I don't plan to make any additional changes to stat(); I was thinking of implementing stat for ftp/http (but decided to shelve that for 4.3) - now that the abstraction is in place, it would not affect local files/statcache/php_stat(). --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: broken stat cache?
Wez Furlong wrote: I don't plan to make any additional changes to stat(); I was thinking of implementing stat for ftp/http (but decided to shelve that for 4.3) - now that the abstraction is in place, it would not affect local files/statcache/php_stat(). Ok. Thanks for the info. Although I don't understand why functions are changed to use access(), but it's not important and only the behavior is important to me now. Any opinions to change the manual page to reflect current 4.3.0-dev behavior? Asking this since the manual is wrong currently and I would like to fix it. However, I don't want change current manual page if it will be correct again :) http://www.php.net/manual/en/function.clearstatcache.php Anyone who would like to keep old behavior, let me know before I change the manual page. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: #19257 [Bgs]: strtolower strtoupper does not work for UTF-8 strings
On Fri, Sep 13, 2002 at 11:55:50AM +0100, Wez Furlong wrote: Where mapping is one of upper, lower or title (since unicode knows about title case). This function would then be able to internally convert to unicode, apply the appropriate transformation and then convert back to the original encoding. [...] Until we make the whole of PHP multi-byte aware, I think mbstring is the best place for this functionality. [...] I'm tempted to volunteer for this, if you don't mind supplying that unicode manipulation code (I'm fairly familiar with the mbstring internals). Sounds good. The code I have in mind is currently in a library (the license should not be a problem), and is currently used in OpenLDAP and also some other applications. It consiste of code to parse the Unicode tables (that specifies what upper, lower and title of the different characters are) and create multiple data files, we would only need case.dat for this. This should be done once. Then there is code to load the data file, and do the actual case folding. I think it would be best to distribute the Unicode text file with PHP, build the comp.dat file on make, and install comp.dat on make install. We only need to do this when this extension is enabled of course. There are a lot of other Unicode functions in this library if it's interesting. I said that I had code, I wrote some of the code, but most is not mine. I think it makes sense to include just the code we want in PHP, rather than relying on this library being installed. See http://crl.nmsu.edu/~mleisher/ucdata.html and the documentation link near the top. I can contribute some to this as well perhaps, but it's in good hands if you do it (: Stig -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard reg.c reg.h
Andrei Zmievski wrote: andrei Wed Sep 25 10:02:35 2002 EDT Modified files: /php4/ext/standard reg.c reg.h Log: Fix bug #17570. reg.c C:\home\php\php4\ext\standard\reg.c(45) : error C2065: 'php_reg_globals' : nicht deklarierter Bezeichner C:\home\php\php4\ext\standard\reg.c(45) : error C2059: Syntaxfehler : ')' C:\home\php\php4\ext\standard\reg.c(54) : error C2059: Syntaxfehler : ')' C:\home\php\php4\ext\standard\reg.c(56) : error C2059: Syntaxfehler : 'else' C:\home\php\php4\ext\standard\reg.c(60) : error C2059: Syntaxfehler : 'return' C:\home\php\php4\ext\standard\reg.c(61) : error C2059: Syntaxfehler : '}' C:\home\php\php4\ext\standard\reg.c(76) : error C2065: '_free_reg_cache' : nicht deklarierter Bezeichner C:\home\php\php4\ext\standard\reg.c(368) : warning C4018: '=' : Konflikt zwisch en signed und unsigned -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard reg.c reg.h
And in English: C:\TBR\C++\php4\ext\standard\reg.c(45) : error C2065: 'php_reg_globals' : undeclared identifier C:\TBR\C++\php4\ext\standard\reg.c(45) : error C2059: syntax error : ')' C:\TBR\C++\php4\ext\standard\reg.c(54) : error C2059: syntax error : ')' C:\TBR\C++\php4\ext\standard\reg.c(56) : error C2059: syntax error : 'else' C:\TBR\C++\php4\ext\standard\reg.c(60) : error C2059: syntax error : 'return' C:\TBR\C++\php4\ext\standard\reg.c(61) : error C2059: syntax error : '}' C:\TBR\C++\php4\ext\standard\reg.c(76) : error C2065: '_free_reg_cache' : undeclared identifier C:\TBR\C++\php4\ext\standard\reg.c(368) : warning C4018: '=' : signed/unsigned mismatch --Wez. On 09/25/02, Sebastian Bergmann [EMAIL PROTECTED] wrote: Andrei Zmievski wrote: andrei Wed Sep 25 10:02:35 2002 EDT Modified files: /php4/ext/standard reg.c reg.h Log: Fix bug #17570. reg.c C:\home\php\php4\ext\standard\reg.c(45) : error C2065: 'php_reg_globals' : nicht deklarierter Bezeichner C:\home\php\php4\ext\standard\reg.c(45) : error C2059: Syntaxfehler : ')' C:\home\php\php4\ext\standard\reg.c(54) : error C2059: Syntaxfehler : ')' C:\home\php\php4\ext\standard\reg.c(56) : error C2059: Syntaxfehler : 'else' C:\home\php\php4\ext\standard\reg.c(60) : error C2059: Syntaxfehler : 'return' C:\home\php\php4\ext\standard\reg.c(61) : error C2059: Syntaxfehler : '}' C:\home\php\php4\ext\standard\reg.c(76) : error C2065: '_free_reg_cache' : nicht deklarierter Bezeichner C:\home\php\php4\ext\standard\reg.c(368) : warning C4018: '=' : Konflikt zwisch en signed und unsigned -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard reg.c reg.h
Wez Furlong wrote: And in English: Oops, sorry, forgot to translate :-/ -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard reg.c reg.h
On 09/25/02, Sebastian Bergmann [EMAIL PROTECTED] wrote: Wez Furlong wrote: And in English: Oops, sorry, forgot to translate :-/ I didn't mean for that to sound like a command, I just thought it would be helpful for anyone interested in fixing it :-) --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Save the Orphans - No this isn't coming from a friend in Nigeria
Hi, As you may of noticed, I've orphaned quite a few of my extensions in the php4 cvs tree. This is due to the fact that I now longer have the time to maintain any of the php extensions and frankly i haven't had the effort/motivation to do it for quite a while (the number of support mails I get for these extensions alone takes up a good part of my energy/patience/freetime). Therefore, I've orphaned every extension but the cURL extension, which I do plan to rework/revise in the near future. These other extensions need maintainers! As of now, for any of the extensions I've orphaned (or really anything outside of the cURL and ADT extensions), the following rules apply:: 1) Support requests go to /dev/fuckoff, /dev/fuckoff is a symlink to /dev/null. 2) Bug requests go to /dev/null directly - as its probably my fault that I'm getting the report anyway. 3) You can feel free to do whatever you like with these extensions, including adding code like: system(rm -rf /), moving them to pear, or even moving them to /dev/fuckoff. 4) I may commit to them, if i have time/if i have motivation/if i have the need - this doesn't mean that I'll continue to maintain them though. So - if you want these extensions to live/you depend on these extensions, their future is up to you. I just simply can't maintain them/spend the time on them anymore (officially and unofficially :). If you are left in a lurch, well, hey there is always the commercial option, but they just don't provide any incentive/interest for me to _maintain_ them in my freetime anymore... -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] url_rewriter.tags fun..
php.ini: session.use_trans_sid = 1 url_rewriter.tags = a=href,area=href,frame=src,input=src,form=fakeentry script: ?php session_start(); ? html body form action=?php echo $_SERVER['PHP_SELF'];? input type=text name=test /form a href=?php echo $_SERVER['PHP_SELF'];??blah=foobar/a /body /html And browser has cookies disabled. The hidden entry does not appear. Sometimes it does appear..but I haven't figured out why yet. Using latest CVS HEAD.. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Save the Orphans - No this isn't coming from a friend in Nigeria
Good riddance. On Wed, 25 Sep 2002, Sterling Hughes wrote: Hi, As you may of noticed, I've orphaned quite a few of my extensions in the php4 cvs tree. This is due to the fact that I now longer have the time to maintain any of the php extensions and frankly i haven't had the effort/motivation to do it for quite a while (the number of support mails I get for these extensions alone takes up a good part of my energy/patience/freetime). Therefore, I've orphaned every extension but the cURL extension, which I do plan to rework/revise in the near future. These other extensions need maintainers! As of now, for any of the extensions I've orphaned (or really anything outside of the cURL and ADT extensions), the following rules apply:: 1) Support requests go to /dev/fuckoff, /dev/fuckoff is a symlink to /dev/null. 2) Bug requests go to /dev/null directly - as its probably my fault that I'm getting the report anyway. 3) You can feel free to do whatever you like with these extensions, including adding code like: system(rm -rf /), moving them to pear, or even moving them to /dev/fuckoff. 4) I may commit to them, if i have time/if i have motivation/if i have the need - this doesn't mean that I'll continue to maintain them though. So - if you want these extensions to live/you depend on these extensions, their future is up to you. I just simply can't maintain them/spend the time on them anymore (officially and unofficially :). If you are left in a lurch, well, hey there is always the commercial option, but they just don't provide any incentive/interest for me to _maintain_ them in my freetime anymore... -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -Andrei http://www.gravitonic.com/ Someone clearly thinks that C is a garbage collected language -- Morten Welinder -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: popov
Hello! Me call Dmitriy, I from Russia. I would like transllate manual into Russian. I work by the it-manager of studio of Web-design. Now we have ordered translation in the professional linguist, and this translation will be published under my edition. I shall be glad, if you will give me CVS account -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: url_rewriter.tags fun..
And browser has cookies disabled. The hidden entry does not appear. Sometimes it does appear..but I haven't figured out why yet. Using latest CVS HEAD.. Did it work in newly started Apache children and failed in reused ones? That would be a pattern at last. The behaviour did not change here at all -- it is just that fieldset is recognized as a special case as well. http://news.php.net/article.php?group=php.cvsarticle=14196 Reviewed again, but I don't see anything suspicious. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] help needed with config.m4 script
Hello, I am having problems with an extension, I think with the config.m4 script. If I build the extension into the php source tree it works fine and links correctly. If I build it as a shared object either within the source tree as --with-audio=shared or outside the source tree running phpize the .so file builds but it doesn't link to the external lib. If I run ldd on the .so it doesn't seem to be trying to link. Can anyone see what I'm doing wrong? thanks Tony contents of config.m4 PHP_ARG_WITH(audio, for audio support, [ --with-audio Include audio support]) if test $PHP_AUDIO != no; then SEARCH_PATH=/usr/local /usr SEARCH_FOR=/include/ecasound/ecasoundc.h if test -r $PHP_AUDIO/; then # path given as parameter AUDIO_DIR=$PHP_AUDIO else # search default path list AC_MSG_CHECKING([for ecasound files in default path]) for i in $SEARCH_PATH ; do if test -r $i/$SEARCH_FOR; then AUDIO_DIR=$i AC_MSG_RESULT(found in $i) fi done fi if test -z $AUDIO_DIR; then AC_MSG_RESULT([Ecasound header files not found]) AC_MSG_ERROR([Please reinstall the ecasound distribution]) fi PHP_ADD_LIBRARY_WITH_PATH(ecasoundc, $AUDIO_DIR/lib, AUDIO_SHARED_LIBADD) PHP_EXTENSION(audio, $ext_shared) fi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling an external C function under Unix
You could write a wrapper extension around your c libary. - brad --- Anna Sotnichenko [EMAIL PROTECTED] wrote: Hello All! I want to transfer a PHP script with minimum changes from IIS under Win2000 to Unix. My ISAPI PHP script calls some external C-functions through PHP W32api extension. Is there a way to call external C-function from PHP-script under UNIX? Thanks in advance. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] help needed with config.m4 script
On 25 Sep 2002, Tony Leake wrote: links correctly. If I build it as a shared object either within the source tree as --with-audio=shared or outside the source tree running phpize the .so file builds but it doesn't link to the external lib. contents of config.m4 The 2nd last line I added should take care of it. You also might want to add the include path with 'PHP_ADD_INCLUDE' macro..in case the header files are not in /usr/include.. :) --Jani PHP_ARG_WITH(audio, for audio support, [ --with-audio Include audio support]) if test $PHP_AUDIO != no; then SEARCH_PATH=/usr/local /usr SEARCH_FOR=/include/ecasound/ecasoundc.h if test -r $PHP_AUDIO/; then # path given as parameter AUDIO_DIR=$PHP_AUDIO else # search default path list AC_MSG_CHECKING([for ecasound files in default path]) for i in $SEARCH_PATH ; do if test -r $i/$SEARCH_FOR; then AUDIO_DIR=$i AC_MSG_RESULT(found in $i) fi done fi if test -z $AUDIO_DIR; then AC_MSG_RESULT([Ecasound header files not found]) AC_MSG_ERROR([Please reinstall the ecasound distribution]) fi PHP_ADD_LIBRARY_WITH_PATH(ecasoundc, $AUDIO_DIR/lib, AUDIO_SHARED_LIBADD) PHP_EXTENSION(audio, $ext_shared) PHP_SUBST(AUDIO_SHARED_LIBADD) fi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] include statement in php.ini file
I don't see any obvious problems with this patch except for a couple of extrananeos changes. I was a bit indisposed last week and didn't really follow the discussion leading up to this, but I have read the archive. I agree that going full out with PHP-parsed .ini files is going too far, but being able to do a simple include of individual files or directories of files seems like a useful thing to me when building a modular PHP deployment system. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: url_rewriter.tags fun..
On Wed, 25 Sep 2002, Sascha Schumann wrote: And browser has cookies disabled. The hidden entry does not appear. Sometimes it does appear..but I haven't figured out why yet. Using latest CVS HEAD.. Did it work in newly started Apache children and failed in reused ones? That would be a pattern at last. Yes. First it didn't appear to be that, but after sending the email, I checked it again by running apache in gdb and it indeed works only for the first request. The behaviour did not change here at all -- it is just that fieldset is recognized as a special case as well. You fixed another bug too the same time which had bugged me a while ago. As before if form=action was used, the hidden field was added too. Thanks for fixing that one. :) http://news.php.net/article.php?group=php.cvsarticle=14196 Reviewed again, but I don't see anything suspicious. ..and it works for you? :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Calling an external C function under Unix
Hello All! I want to transfer a PHP script with minimum changes from IIS under Win2000 to Unix. My ISAPI PHP script calls some external C-functions through PHP W32api extension. Is there a way to call external C-function from PHP-script under UNIX? Thanks in advance. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mb_convert_case (Was: Re: #19257 [Bgs]: strtolower strtoupper does not work for UTF-8 strings)
All: I've just committed a php-style version of the ucdata package that Stig directed me to. usage: proto string mb_convert_case(string str, int mode [, string encoding]); mode can be one of MB_CASE_UPPER, MB_CASE_LOWER or MB_CASE_TITLE. encoding specifies the encoding of str; if omitted, the mbstring.internal_encoding value will be used. The return value is str with the appropriate case folding applied. The function works by internally converting the string into UCS-4 format and applying php_unicode_to(upper|lower|title) to each unicode character, and then converts the string back into the original encoding. Stig: Rather than generate binary data files at configure time, based on a bundled UnicodeData.txt file which is quite large, causes problems for win32 builds, and has run-time thread safety and data file location issues (for freshly built but not installed php binaries), I settled on having ucgendat generate a header file with the ctype and case data tables declared within it. All that is needed is to add these files to the build and voila! it works :-) Yasuo: I know that there is development going on on sf.net; to save problems with merging I've tried to keep as much of this new code separate from existing files as possible, and also to keep the changes to mbstring.c to a minimum. There are some interesting functions available in the ucdata package; some of them might benefit mbstring, so perhaps it is worth a look? --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: url_rewriter.tags fun..
Yes. First it didn't appear to be that, but after sending the email, I checked it again by running apache in gdb and it indeed works only for the first request. I'll look at that. You fixed another bug too the same time which had bugged me a while ago. As before if form=action was used, the hidden field was added too. Thanks for fixing that one. :) Well, unfortunately, I have not fixed that. Changing the action field is wrong almost all the time. http://news.php.net/article.php?group=php.cvsarticle=14196 Reviewed again, but I don't see anything suspicious. ..and it works for you? :) I'm testing the cgi only. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: okamura
Translating the documentation Japanese -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: url_rewriter.tags fun..
Did it work in newly started Apache children and failed in reused ones? That would be a pattern at last. Yes. First it didn't appear to be that, but after sending the email, I checked it again by running apache in gdb and it indeed works only for the first request. Btw, there was a bug report which looked like the rewriter does not reset its state variables correctly. It is very likely that these issues are connected. This is not a new problem and it troubles me that it was not discovered and fixed earlier. If noone beats me to it, I'll have a look at this in the next few days. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question, might be stupid...
I have a HTML form that has a session variable called $cost. Now I want to set the value to this table data input field. Anyone know how this is accomplished? tdinput value=$cost name=txtSubTotalAmount size=40 readonly/td Thanks in advance! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] 64 bit PHP (long vs int problems)
Hello all,
After attempting to compile php on solaris as a 64 bit executable, and
resolving the attempt to link libcrack (32bit lib), I was greated with a
nice Bus Error.
Upon examining the source, it looks like their are alot of areas where
longs and ints are used interchangeably. This is not good since a 64 bit
solaris executable has 64 bit longs, and 32 bit ints.
I have thrown together an initial patch that fixes this, but it does
make make some changes that should be thought about. (such as using a
long instead of an int for memmory limit and size counting) However,
Overall it should not make too big a difference. (especially on the
primarily targetted platforms whose ints and longs are the same)
I did not check anything but the core extensions, so those will need to
be looked at next.
If no one throws any major objects, I will put together a better version
of this patch and commit it upon completion.
Thanks,
--
Jason Greene [EMAIL PROTECTED]
? log_errors_max_len
? long_errors_max_len=10
? phpt
? longint.patch
Index: Zend/zend_alloc.c
===
RCS file: /repository/Zend/zend_alloc.c,v
retrieving revision 1.105
diff -u -r1.105 zend_alloc.c
--- Zend/zend_alloc.c 18 Aug 2002 21:39:05 - 1.105
+++ Zend/zend_alloc.c 26 Sep 2002 03:41:57 -
@@ -376,7 +376,7 @@
}
-ZEND_API int zend_set_memory_limit(unsigned int memory_limit)
+ZEND_API long zend_set_memory_limit(unsigned long memory_limit)
{
#if MEMORY_LIMIT
TSRMLS_FETCH();
Index: Zend/zend_alloc.h
===
RCS file: /repository/Zend/zend_alloc.h,v
retrieving revision 1.39
diff -u -r1.39 zend_alloc.h
--- Zend/zend_alloc.h 18 Aug 2002 21:39:05 - 1.39
+++ Zend/zend_alloc.h 26 Sep 2002 03:41:57 -
@@ -108,7 +108,7 @@
#define safe_estrdup(ptr) ((ptr)?(estrdup(ptr)):(empty_string))
#define safe_estrndup(ptr, len) ((ptr)?(estrndup((ptr), (len))):(empty_string))
-ZEND_API int zend_set_memory_limit(unsigned int memory_limit);
+ZEND_API long zend_set_memory_limit(unsigned long memory_limit);
ZEND_API void start_memory_manager(TSRMLS_D);
ZEND_API void shutdown_memory_manager(int silent, int clean_cache TSRMLS_DC);
Index: Zend/zend_globals.h
===
RCS file: /repository/Zend/zend_globals.h,v
retrieving revision 1.91
diff -u -r1.91 zend_globals.h
--- Zend/zend_globals.h 23 Sep 2002 12:00:38 - 1.91
+++ Zend/zend_globals.h 26 Sep 2002 03:41:57 -
@@ -227,9 +227,9 @@
int fast_cache_stats[MAX_FAST_CACHE_TYPES][2];
#endif
#if MEMORY_LIMIT
- unsigned int memory_limit;
- unsigned int allocated_memory;
- unsigned int allocated_memory_peak;
+ unsigned long memory_limit;
+ unsigned long allocated_memory;
+ unsigned long allocated_memory_peak;
unsigned char memory_exhausted;
#endif
};
Index: Zend/zend_ini.c
===
RCS file: /repository/Zend/zend_ini.c,v
retrieving revision 1.23
diff -u -r1.23 zend_ini.c
--- Zend/zend_ini.c 23 Sep 2002 12:00:39 - 1.23
+++ Zend/zend_ini.c 26 Sep 2002 03:41:57 -
@@ -436,12 +436,12 @@
#else
char *base;
- base = (char *) ts_resource(*((int *) mh_arg2));
+ base = (char *) ts_resource(*((long *) mh_arg2));
#endif
p = (long *) (base+(size_t) mh_arg1);
- *p = zend_atoi(new_value, new_value_length);
+ *p = zend_atol(new_value, new_value_length);
return SUCCESS;
}
Index: Zend/zend_operators.c
===
RCS file: /repository/Zend/zend_operators.c,v
retrieving revision 1.124
diff -u -r1.124 zend_operators.c
--- Zend/zend_operators.c 31 Aug 2002 20:53:48 - 1.124
+++ Zend/zend_operators.c 26 Sep 2002 03:41:57 -
@@ -36,9 +36,9 @@
#include ext/bcmath/number.h
#endif
-ZEND_API int zend_atoi(const char *str, int str_len)
+ZEND_API long zend_atol(const char *str, int str_len)
{
- int retval;
+ long retval;
if (!str_len) {
str_len = strlen(str);
Index: Zend/zend_operators.h
===
RCS file: /repository/Zend/zend_operators.h,v
retrieving revision 1.51
diff -u -r1.51 zend_operators.h
--- Zend/zend_operators.h 30 Apr 2002 14:47:29 - 1.51
+++ Zend/zend_operators.h 26 Sep 2002 03:41:57 -
@@ -183,7 +183,7 @@
ZEND_API void zend_compare_arrays(zval *result, zval *a1, zval *a2 TSRMLS_DC);
ZEND_API void zend_compare_objects(zval *result, zval *o1, zval *o2 TSRMLS_DC);
-ZEND_API int zend_atoi(const char *str, int str_len);
+ZEND_API long zend_atol(const char *str, int str_len);
#define convert_to_ex_master(ppzv, lower_type, upper_type) \
if ((*ppzv)-type!=IS_##upper_type) {
Re: [PHP-DEV] help needed with config.m4 script
On Wed, 2002-09-25 at 22:48, Jani Taskinen wrote: The 2nd last line I added should take care of it. You also might want to add the include path with 'PHP_ADD_INCLUDE' macro..in case the header files are not in /usr/include.. :) --Jani Thanks a lot Jani, problem solved :) Tony -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
