Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
On Wed, 16 Oct 2002, Melvyn Sopacua wrote: At 23:13 15-10-2002, Yasuo Ohgaki wrote: Another option. How about remove $_FILES contents from $_REQUEST? It seems it has less impact. I don't think Zeev and Derick will be able to go on any trips for a while then :-) First 'force' people to use superglobals, then say ehm - yeah, but ehm uploaded files are not userdata, because they are not in $_REQUEST. I would have no problem with leaving out $_FILES from $_REQUEST... 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
Re: [PHP-DEV] Re: [4.3] Current critical bugs
On Tue, Oct 15, 2002 at 06:33:33PM +0200, Markus Fischer wrote: On Tue, Oct 15, 2002 at 06:23:17PM +0200, Tom Sommer wrote : Andrei Zmievski wrote: Summary: max_execution_time affects large uploads URL: http://bugs.php.net/bug.php?id=16880 [...] I neither think this is critical nor a real problem. Thank god a big/long file upload is captured by the time limit, else we would have another DoS. I think long time uploads should be allowed. On slow network links, there are people that can download 10MB mailbox even for 30 minutes. TIP: Maybe user/admin can set time limit to 2 minutes, and CPU usage to 10 seconds. On unix platform there is a pretty good function called setrlimit() but it can limit CPU usage per process only, not per Apache request. But it should be possible to check every 'x' seconds user/system CPU usage with getrlimit() ... This would be even better anti-DOS feature, since some user php scripts with bugs could run at 100% CPU for (20 seconds max_execution_time is loo long for such scripts, and too short for others). Best regards, -- Piotr Klaban -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
While I think it is a bit unintuitive to have $_FILES separate like it is (rather than a part of $_POST, for example), I think it would be much worse to also separate it from $_REQUEST. After all, as Sterling pointed out, it is part of the request. Chris Derick Rethans wrote: On Wed, 16 Oct 2002, Melvyn Sopacua wrote: At 23:13 15-10-2002, Yasuo Ohgaki wrote: Another option. How about remove $_FILES contents from $_REQUEST? It seems it has less impact. I don't think Zeev and Derick will be able to go on any trips for a while then :-) First 'force' people to use superglobals, then say ehm - yeah, but ehm uploaded files are not userdata, because they are not in $_REQUEST. I would have no problem with leaving out $_FILES from $_REQUEST... Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : While I think it is a bit unintuitive to have $_FILES separate like it is (rather than a part of $_POST, for example), I think it would be much worse to also separate it from $_REQUEST. After all, as Sterling pointed out, it is part of the request. It makes quite sense to me that _FILES is separate. It is much easier that way to iterate through multiple uploaded files without much hassle. -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc rei_ Derick, while ($xml) $ass-get_new_ideas(); [James] Markus: IE on_user_fart() -- People doesn't seem to like the new XHTML2 specs :) -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
On Wed, 16 Oct 2002, Markus Fischer wrote: On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : While I think it is a bit unintuitive to have $_FILES separate like it is (rather than a part of $_POST, for example), I think it would be much worse to also separate it from $_REQUEST. After all, as Sterling pointed out, it is part of the request. It makes quite sense to me that _FILES is separate. It is much easier that way to iterate through multiple uploaded files without much hassle. Another good point to keep them seperate :) But of course that whould have been possible anyway, wheter it's possible to access ot from the $_REQUEST hash or not.. 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: [PHP-CVS] cvs: php4 /main config.w32.h.in
Unless you fix the rest of the occurences of these symbolic defines this patch (which is the same Stig commited) is a bit problematic and will not work properly. Take a look at http://lxr.php.net/source/php4/main/main.c#1100 and see how PEAR_INSTALL_DIR is registered; sizeof() doesn't work as you might expect with the CONDENV construct. Please test before commit: C:\cygwin\home\mfischer\isrc\cvs\php4\Debug_TSphp test.php Warning: String is not zero-terminated (c:\php4\pear) (source: c:\cygwin\home\mfischer\isrc\cvs\php4\zend\zend_constants .c:239) in C:\cygwin\home\mfischer\isrc\cvs\php4\Debug_TS\test.php on line 2 string(3) c:\ C:\cygwin\home\mfischer\isrc\cvs\php4\Debug_TSset PEAR_INSTALLDIR=whatever C:\cygwin\home\mfischer\isrc\cvs\php4\Debug_TSphp test.php Warning: String is not zero-terminated (whatever) (source: c:\cygwin\home\mfischer\isrc\cvs\php4\zend\zend_constants.c:2 39) in C:\cygwin\home\mfischer\isrc\cvs\php4\Debug_TS\test.php on line 2 string(3) wha - Markus On Wed, Oct 16, 2002 at 07:37:28AM -, Sebastian Bergmann wrote : sebastian Wed Oct 16 03:37:28 2002 EDT Modified files: /php4/mainconfig.w32.h.in Log: Patch by Urs Gehrig [EMAIL PROTECTED]. Index: php4/main/config.w32.h.in diff -u php4/main/config.w32.h.in:1.17 php4/main/config.w32.h.in:1.18 --- php4/main/config.w32.h.in:1.17Fri Oct 11 05:20:38 2002 +++ php4/main/config.w32.h.in Wed Oct 16 03:37:28 2002 @@ -2,22 +2,24 @@ Build Configuration for Win32. This has only been tested with MS VisualC++ 6 (and later). - $Id: config.w32.h.in,v 1.17 2002/10/11 09:20:38 edink Exp $ + $Id: config.w32.h.in,v 1.18 2002/10/16 07:37:28 sebastian Exp $ */ +#define CONDENV(ev,def) (getenv(ev)!=NULL?getenv(ev):def) + /* Default PHP / PEAR directories */ -#define CONFIGURATION_FILE_PATH php.ini -#define PEAR_INSTALLDIR c:\\php4\\pear -#define PHP_BINDIR c:\\php4 -#define PHP_CONFIG_FILE_PATH (getenv(SystemRoot))?getenv(SystemRoot): -#define PHP_CONFIG_FILE_SCAN_DIR -#define PHP_DATADIR c:\\php4 -#define PHP_EXTENSION_DIR c:\\php4 -#define PHP_INCLUDE_PATH .;c:\\php4\\pear -#define PHP_LIBDIR c:\\php4 -#define PHP_LOCALSTATEDIR c:\\php4 -#define PHP_PREFIX c:\\php4 -#define PHP_SYSCONFDIR c:\\php4 +#define CONFIGURATION_FILE_PATH php.ini +#define PEAR_INSTALLDIR CONDENV(PEAR_INSTALLDIR, c:\\php4\\pear) +#define PHP_BINDIRCONDENV(PHP_BINDIR, c:\\php4) +#define PHP_CONFIG_FILE_PATH CONDENV(SystemRoot, ) +#define PHP_CONFIG_FILE_SCAN_DIR CONDENV(PHP_CONFIG_FILE_SCAN_DIR, ) +#define PHP_DATADIR CONDENV(PHP_DATADIR, c:\\php4) +#define PHP_EXTENSION_DIR c:\\php4 +#define PHP_INCLUDE_PATH .;c:\\php4\\pear +#define PHP_LIBDIRCONDENV(PHP_LIBDIR, c:\\php4) +#define PHP_LOCALSTATEDIR CONDENV(PHP_LOCALSTATEDIR, c:\\php4) +#define PHP_PREFIXCONDENV(PHP_PREFIX, c:\\php4) +#define PHP_SYSCONFDIRCONDENV(PHP_SYSCONFDIR, c:\\php4) /* Enable / Disable BCMATH extension (default: enabled) */ #define WITH_BCMATH 1 -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc rei_ Derick, while ($xml) $ass-get_new_ideas(); [James] Markus: IE on_user_fart() -- People doesn't seem to like the new XHTML2 specs :) -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] OCI extension help offer
I'm sure glad this in the headlines again ;-) As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session environment (- as a global one). Oracle 9i offers some functions which help out from this dilemma, and I have changed the existing oci ext to support them. The most important change (from a user's viewpoint) is that OCILogon has an optional forth parameter, the character set, so an connection looks like this: OCILogon($user,$pass,$tnsname,WE8ISO8859P1); Ok, I know this isn't ideal, since OCILogon already has an optional parameter, but maybe people can set $tnsname to false if they want to use the default one (ORACLE_SID) and use a specific character set? Anyway, my code works, and is already being used in a relativly big production environment. From a developers viewpoint what I mainly did was follow Thies' proposal and put the environment struct in the session struct, and use the global env only for init work. Then I decode the character set parameter (if it is omitted, the NLS_LANG setting or Oracle default will be used) and use it in open_session. Voila, Oracle takes care of the rest. Works better than I thought :-). The only thing I need to do now is to add a compile-time decision on whether Ora9i libraries are found or not, and then to make this functionality available depending on the version. If anyone's interested I can send a patch.. As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and 2. there is absolutely zero effectiveness in merging the ora_ and OCI extensions, which differ greatly, into one. I think that would result in a mess or a big rewrite.. Thx, Cu Abdul Sebastian Nohn [EMAIL PROTECTED] writes: 5. Functions are called OCI .* I do well know what it refers to, but this is only because I learned the original oci.h API. Wouldn't itbe more standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions ect? OCI make it a bit confusing, I always heard from my co-workers. Besides, this can also be a great input for newer Oracle's updates. This is mainly because there are Oracle-funktions and OCI-functions (there is a difference), and i like the OCI-thing very much, it's much easier and faster to type than oracle ;) Well, yes, OCI* functions look pretty geek, indeed, they are very similar (if not identic, in some its parts) to the actual OCI API. But, this naming convention is way not optimal, is limited functionality-wise and, last but not least, it is far not PHP's standard naming convention for the database extensions. In fact, if you'll look into PHP standards specifications (look in CVS: http://cvs.php.net/co.php/php4/CODING_STANDARDS?login=2r=1.23) you are encoraged using a certain style for calling your functions, especially those of databases since these mostly do the same things. What I meant was, while to access a mySQL database you use mysql_connect(), for PostgreSQL pg_connect() and for Sybase sybase_connect() question stays: why function to connect to Oracle be called OCILogon()? Wouldn't it be better called oracle_connect()? that is how som other programming languages call it. It is not an exaggeration to say that, some programmers are actually making their own functions named this very way so they can easier interact with the Oracle database using their mySQL's (or whatever) habbits because OCI gets them confused. I kind of followed this question within the PHP-Oracle developers I met. For now, we have ora_* and OCI* functions. These are, as long as I understand, used for Oracle v6.* and Oracle v8 (the last one is also 90% compatible with v9). Yet, this shouldn't mean that there is no need for a standarized set of functions like oracle_* with mapped/intuitive functionalities like most of the DBs PHP that supports AND as compatible between Oracle versions as possible. Only this way, one could firmly admit that PHP fully supports Oracle database. Those are my ideas for the Oracle extension. At this point, some new questions arised in my head: 1. Is ora_* extension (ext/oracle) still maintained and ported compatibility-wise to the versions Oracle newer v6 or, for these are OCI8 extensions? If so, then this should mean that ora_* functions are limited to version 6 only, if not deprecated at all. Am I correct, or missed the point? If I guessed, then what was the need for OCI8 extyension at all? Why ora_* could not be continued? I still haven't found it out. 2. What costs merging the two extensions (ora_* and OCI8) in one (oracle_* ?) that fully supports both 6*, 8* and 9* versions of Oracle and remains the only one to be used (as well as maintained, debugged) in the feature? 3. Still, related to question 2: Wouldn't it be
Re: Re: Re: [PHP-DEV] OCI extension help offer
Oh, and just to be clear about it: I am absolutely positive on a completely new (perhaps unified) extension for PHP 5, and would gladly participate. I Just don't think that changing anything in the current situation would be useful. Abdul [EMAIL PROTECTED] schrieb am 16.10.02 10:22:18: I'm sure glad this in the headlines again ;-) As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session environment (- as a global one). Oracle 9i offers some functions which help out from this dilemma, and I have changed the existing oci ext to support them. The most important change (from a user's viewpoint) is that OCILogon has an optional forth parameter, the character set, so an connection looks like this: OCILogon($user,$pass,$tnsname,WE8ISO8859P1); Ok, I know this isn't ideal, since OCILogon already has an optional parameter, but maybe people can set $tnsname to false if they want to use the default one (ORACLE_SID) and use a specific character set? Anyway, my code works, and is already being used in a relativly big production environment. From a developers viewpoint what I mainly did was follow Thies' proposal and put the environment struct in the session struct, and use the global env only for init work. Then I decode the character set parameter (if it is omitted, the NLS_LANG setting or Oracle default will be used) and use it in open_session. Voila, Oracle takes care of the rest. Works better than I thought :-). The only thing I need to do now is to add a compile-time decision on whether Ora9i libraries are found or not, and then to make this functionality available depending on the version. If anyone's interested I can send a patch.. As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and 2. there is absolutely zero effectiveness in merging the ora_ and OCI extensions, which differ greatly, into one. I think that would result in a mess or a big rewrite.. Thx, Cu Abdul Sebastian Nohn [EMAIL PROTECTED] writes: 5. Functions are called OCI .* I do well know what it refers to, but this is only because I learned the original oci.h API. Wouldn't itbe more standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions ect? OCI make it a bit confusing, I always heard from my co-workers. Besides, this can also be a great input for newer Oracle's updates. This is mainly because there are Oracle-funktions and OCI-functions (there is a difference), and i like the OCI-thing very much, it's much easier and faster to type than oracle ;) Well, yes, OCI* functions look pretty geek, indeed, they are very similar (if not identic, in some its parts) to the actual OCI API. But, this naming convention is way not optimal, is limited functionality-wise and, last but not least, it is far not PHP's standard naming convention for the database extensions. In fact, if you'll look into PHP standards specifications (look in CVS: http://cvs.php.net/co.php/php4/CODING_STANDARDS?login=2r=1.23) you are encoraged using a certain style for calling your functions, especially those of databases since these mostly do the same things. What I meant was, while to access a mySQL database you use mysql_connect(), for PostgreSQL pg_connect() and for Sybase sybase_connect() question stays: why function to connect to Oracle be called OCILogon()? Wouldn't it be better called oracle_connect()? that is how som other programming languages call it. It is not an exaggeration to say that, some programmers are actually making their own functions named this very way so they can easier interact with the Oracle database using their mySQL's (or whatever) habbits because OCI gets them confused. I kind of followed this question within the PHP-Oracle developers I met. For now, we have ora_* and OCI* functions. These are, as long as I understand, used for Oracle v6.* and Oracle v8 (the last one is also 90% compatible with v9). Yet, this shouldn't mean that there is no need for a standarized set of functions like oracle_* with mapped/intuitive functionalities like most of the DBs PHP that supports AND as compatible between Oracle versions as possible. Only this way, one could firmly admit that PHP fully supports Oracle database. Those are my ideas for the Oracle extension. At this point, some new questions arised in my head: 1. Is ora_* extension (ext/oracle) still maintained and ported compatibility-wise to the versions Oracle newer v6 or, for these are OCI8 extensions? If so, then this should mean that ora_* functions are limited to version 6 only, if not deprecated at all. Am I correct, or missed the point? If I guessed, then what was the need for OCI8
Re[2]: [PHP-DEV] short_open_tag
Hello Dan, Tuesday, October 15, 2002, 7:41:16 PM, you wrote: DH The web is a rapidly changing market and standards are being activley DH evolved. ?php is more compatable with standards on the web than ? ... DH and its not about XML document headers. Yes, the web is rapidly changing, but PHP shouldn't and couldn't change so fast. DH I have written semi static XML document from php before (for speed reasons DH over using an output parser). EG: DH ?xml ... ? DH root DH data DH age?php echo $age; ?/age DH /data DH /root You can disable short_tags on 99% of hostings yourself. By disabling short_tags we can solve one small problem and obtain one really BIG. DH The other advantage is to force people one way or the other. In the case DH of 50% of servers allowing short tags, and the other not... a script using DH short tags will only work on 50% of PHP installations (just as a script DH that relies on register_globals will only work on servers with it switched DH on). Hmmm.. I don't see any advantage in forcing people at all. People MUST have choice(and possibility to learn on their own mistakes). I think we can finish this discussion. The answer is NO. Antony Dovgal aka tony2001 mailto:[EMAIL PROTECTED] http://phpclub.net -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
[EMAIL PROTECTED] wrote... : I'm sure glad this in the headlines again ;-) As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session environment (- as a global one). Oracle 9i offers some functions which help out from this dilemma, and I have changed the existing oci ext to support them. The most important change (from a user's viewpoint) is that OCILogon has an optional forth parameter, the character set, so an connection looks like this: OCILogon($user,$pass,$tnsname,WE8ISO8859P1); Ok, I know this isn't ideal, since OCILogon already has an optional parameter, but maybe people can set $tnsname to false if they want to use the default one (ORACLE_SID) and use a specific character set? Anyway, my code works, and is already being used in a relativly big production environment. Well, ideally, there would be a function for charset to be called before any OCIParse and set the charset. This would be: 1. more flexible 2. would exclude non-authentication functionality with OCILogon 3. easier to find for a user From a developers viewpoint what I mainly did was follow Thies' proposal and put the environment struct in the session struct, and use the global env only for init work. Then I decode the character set parameter (if it is omitted, the NLS_LANG setting or Oracle default will be used) and use it in open_session. Voila, Oracle takes care of the rest. Works better than I thought :-). The only thing I need to do now is to add a compile-time decision on whether Ora9i libraries are found or not, and then to make this functionality available depending on the version. If anyone's interested I can send a patch.. Well, let's ask Thies if he wants the patch, as I have no karma to php4 anyway :) As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and No way,I meant to drop the existing compatibility :). I'd keep the existing OCI8 extension, as well as I would keep ora_* functions. I would simply add the earlier suggested oracle_* functions to be something understood as a default Oracle extension similar to the way other DBs work. That's my idea. the -1's are that someone can get confused. But, nothing is free, I think a bit of confusion is the minimal expense for such functionality. it's already confusing anyway. 2. there is absolutely zero effectiveness in merging the ora_ and OCI extensions, which differ greatly, into one. I think that would result in a mess or a big rewrite.. Wouldn't it be better, though? Yes, perhaps it would be a big rewrite, but it would definitely create an actual Oracle extension, not two version-specific ones. Really, it is confusing. Try imagine a similar situation: Whoever pays Oracle license is planning something big and costly. A such user would have no much trouble paying also for Java or ASP, that support Oracle pretty well, but, should the corp. prefer PHP, they'd consider this more than once. This is because they would be soon confused about how things are working between PHP and Oracle, what Oracle versions are supported and for how long... Then, automatically (in some heads) answer arises: Yeah, PHP is Open Source, it won't support well commercial third parties That is why I think that unifying Oracle into something that looks and works just as other Open Source DBs can help PHP (5?) gain better trust and confidence from middle-large projects worldwide. I have this theory not from air, but from my experience as a consultant trying propose PHP for Oracle Dbs :) Maxim Maletsky [EMAIL PROTECTED] Thx, Cu Abdul Sebastian Nohn [EMAIL PROTECTED] writes: 5. Functions are called OCI .* I do well know what it refers to, but this is only because I learned the original oci.h API. Wouldn't itbe more standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions ect? OCI make it a bit confusing, I always heard from my co-workers. Besides, this can also be a great input for newer Oracle's updates. This is mainly because there are Oracle-funktions and OCI-functions (there is a difference), and i like the OCI-thing very much, it's much easier and faster to type than oracle ;) Well, yes, OCI* functions look pretty geek, indeed, they are very similar (if not identic, in some its parts) to the actual OCI API. But, this naming convention is way not optimal, is limited functionality-wise and, last but not least, it is far not PHP's standard naming convention for the database extensions. In fact, if you'll look into PHP standards specifications (look in CVS: http://cvs.php.net/co.php/php4/CODING_STANDARDS?login=2r=1.23) you are encoraged using a certain style for calling your functions, especially those of databases since
Re: [PHP-DEV] OCI extension help offer
[EMAIL PROTECTED] wrote... : Oh, and just to be clear about it: I am absolutely positive on a completely new (perhaps unified) extension for PHP 5, and would gladly participate. I Just don't think that changing anything in the current situation would be useful. I'd never meant to :) -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re: [PHP-DEV] OCI extension help offer
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 16 octobre 2002 10:22 À : [EMAIL PROTECTED] Objet : Re: Re: [PHP-DEV] OCI extension help offer I'm sure glad this in the headlines again ;-) +1 As Thies knows, I already proposed another important change, which is supporting multiple character sets. Do you know if/when your patch (or similar functionality) will be included in the oci extension ? As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and 2. there is absolutely zero effectiveness in merging the ora_ and OCI extensions, which differ greatly, into one. I think that would result in a mess or a big rewrite.. It might be interesting to change only the extension name from oci8 to oci (which would be less confusing when working with 9i). Unless your code relies on extension names, it will still work. -1 for merging ora_ with oci_ extensions unless you can disable ora_* functions at compile time (I don't want my users to be able to call ora_*). Jean-François -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
It might be interesting to change only the extension name from oci8 to oci (which would be less confusing when working with 9i). Unless your code relies on extension names, it will still work. -1 for merging ora_ with oci_ extensions unless you can disable ora_* functions at compile time (I don't want my users to be able to call ora_*). Why would you need ora_* anyway, assuming there are oracle_* (another extension) that works with all versions of Oracle? ora_* is an extension as well and is not being compiled by default, it mostly serves for the backward compatibility. Just to precise, Merging ... IS NOT: removing ora_* and OCI* while adding oracle_*. Nothing should be removed as that would stop many applications from continuing to work IT IS : adding a new extension which works as other DBs do (oracle_connect(), oracle_num_rows(), oracle_close() etc). Thus, one can still choose not to compile it relaying on the old extensions, or use this one as it would be the only compatible extension constantly maintained. Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // where PHP Begins Jean-François -- 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
Re: [PHP-DEV] [PATCH] New function file_put()
Derick Rethans wrote: Please write a new test for this without piggy backing on the old one. We're trying to get one function tested per tests so that differenc functions in the same test can not be the cause of 'screw-ups'. Ok, I attached a file ext/standard/tests/file/file_put_contents.phpt - Chris -- IOGRAM AG | http://iogram.ch Binzstrasse 7 | 8045 Zürich | Tel. 01 465 45 45 Computers are not intelligent. They only think they are. --TEST-- file_put_contents() function test --POST-- --GET-- --FILE-- ?php $name = tempnam(./ext/standard/tests/file/, php); echo file_put_contents($name, Data to be overwritten\n) . \n; readfile($name); $data = The quick brown fox jumps over the lazy dog\n; echo file_put_contents($name, $data) . \n; readfile($name); $data = array(Apples\n, Oranges\n); echo file_put_contents($name, $data, ab) . \n; readfile($name); unlink($name); ? --EXPECT-- 23 Data to be overwritten 44 The quick brown fox jumps over the lazy dog 15 The quick brown fox jumps over the lazy dog Apples Oranges -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
Hm, quite a few issues... Here are my thoughts regarding one of them. As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session environment (- as a global one). Oracle 9i offers some functions which help out from this dilemma, and I have changed the existing oci ext to support them. The most important change (from a user's viewpoint) is that OCILogon has an optional forth parameter, the character set, so an connection looks like this: OCILogon($user,$pass,$tnsname,WE8ISO8859P1); Ok, I know this isn't ideal, since OCILogon already has an optional parameter, but maybe people can set $tnsname to false if they want to use the default one (ORACLE_SID) and use a specific character set? Anyway, my code works, and is already being used in a relativly big production environment. Well, ideally, there would be a function for charset to be called before any OCIParse and set the charset. This would be: 1. more flexible 2. would exclude non-authentication functionality with OCILogon 3. easier to find for a user Well basically, yes, I would prefer that solution, too. But: OCILogon not only connects to the database, it also opens the session, which is quite correct since a connection without a session isn't very useful. So either we make OCILogon *just* connect to the db and have a useless connection lying around until someone initializes the session (- quite a bit to change + programming logic in php scripts broken, they would have to do two initialization steps), OR we initialize the session together with the connection (as is now) but have to provide the parameter at init time. Wait, there is another possibility: perhaps we can have OCILogon use the global environment OCI(pEnv) to init the session (meaning that it uses the NLS_LANG settings), and then one can (not must) change the environment and from that moment on the new environment is used for the session. But this means we have to have a reliable switching mechanism between global and session-private environments, something I believe to be very tiresome... Besides, we would then have a PHP function that can only be used with oracle 9i, whereas I would prefer to have a parameter that is only supported on such systems. Maybe just a matter of preference, but I feel that a function that is only available in certain compile situations isn't very elegant...? BTW, currently the environment is init'd in php_oci_init_globals using the OCI function OCIEnvInit, which is deprecated. We should try to switch this to the more flexible (and supported) OCIEnvCreate - just as a small note ;-) I included the patches (oci8.c and the corresponding .h) but please remember that currently you will need an Oracle 9i client to compile them (I still need to put some switches and fallback behaviours in there). Cu all, Abdul From a developers viewpoint what I mainly did was follow Thies' proposal and put the environment struct in the session struct, and use the global env only for init work. Then I decode the character set parameter (if it is omitted, the NLS_LANG setting or Oracle default will be used) and use it in open_session. Voila, Oracle takes care of the rest. Works better than I thought :-). The only thing I need to do now is to add a compile-time decision on whether Ora9i libraries are found or not, and then to make this functionality available depending on the version. If anyone's interested I can send a patch.. Well, let's ask Thies if he wants the patch, as I have no karma to php4 anyway :) As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and No way,I meant to drop the existing compatibility :). I'd keep the existing OCI8 extension, as well as I would keep ora_* functions. I would simply add the earlier suggested oracle_* functions to be something understood as a default Oracle extension similar to the way other DBs work. That's my idea. the -1's are that someone can get confused. But, nothing is free, I think a bit of confusion is the minimal expense for such functionality. it's already confusing anyway. 2. there is absolutely zero effectiveness in merging the ora_ and OCI extensions, which differ greatly, into one. I think that would result in a mess or a big rewrite.. Wouldn't it be better, though? Yes, perhaps it would be a big rewrite, but it would definitely create an actual Oracle extension, not two version-specific ones. Really, it is confusing. Try imagine a similar situation: Whoever pays Oracle license is planning something big and costly. A such user would have no much trouble paying also for Java or ASP, that support Oracle pretty well, but, should the corp. prefer PHP, they'd
Re: [PHP-DEV] OCI extension help offer
[EMAIL PROTECTED] schrieb am 16.10.02 12:13:57: It might be interesting to change only the extension name from oci8 to oci (which would be less confusing when working with 9i). Unless your code relies on extension names, it will still work. Nice idea, but I guess this is sheer cosmetics, or do you mean to change any behaviour? Merging ... IS NOT: removing ora_* and OCI* while adding oracle_*. Nothing should be removed as that would stop many applications from continuing to work IT IS : adding a new extension which works as other DBs do (oracle_connect(), oracle_num_rows(), oracle_close() etc). Thus, one can still choose not to compile it relaying on the old extensions, or use this one as it would be the only compatible extension constantly maintained. Well, either that new extension (oracle_*) is a rewrite of the oci8 ext (working with 8+), or you are intending to target oracle 6 - 9i which I would not recommend seeing that there are *so much* differences between the versions. I think that for ora6 + 7 the current (outdated) ora_* ext is enough, and maybe we should concentrate on moving the whole thing forward. Of course we could rewrite the ext, and clean up what has grown historically, and I think this belongs into the planning for php5. Currently though, we should try to consolidate the oracle support so that people have a reliable way of programming for it without having to wait too long. (Consolidation = add data type support for any missing or new types, find a solution for the lob handling (this should be easier for a script developer IMO), and introduce some useful php.ini values (maybe even for default character set?)) Cu, Abdul -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h.in
Markus Fischer wrote: Please test before commit: Well, I only tested whether or not it compiles. Which it does, so it's not the same patch as before. -- 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] OCI extension help offer
[EMAIL PROTECTED] wrote... : Hm, quite a few issues... Here are my thoughts regarding one of them. As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session environment (- as a global one). Oracle 9i offers some functions which help out from this dilemma, and I have changed the existing oci ext to support them. The most important change (from a user's viewpoint) is that OCILogon has an optional forth parameter, the character set, so an connection looks like this: OCILogon($user,$pass,$tnsname,WE8ISO8859P1); Ok, I know this isn't ideal, since OCILogon already has an optional parameter, but maybe people can set $tnsname to false if they want to use the default one (ORACLE_SID) and use a specific character set? Anyway, my code works, and is already being used in a relativly big production environment. Well, ideally, there would be a function for charset to be called before any OCIParse and set the charset. This would be: 1. more flexible 2. would exclude non-authentication functionality with OCILogon 3. easier to find for a user Well basically, yes, I would prefer that solution, too. But: OCILogon not only connects to the database, it also opens the session, which is quite correct since a connection without a session isn't very useful. So either we make OCILogon *just* connect to the db and have a useless connection lying around until someone initializes the session (- quite a bit to change + programming logic in php scripts broken, they would have to do two initialization steps), OR we initialize the session together with the connection (as is now) but have to provide the parameter at init time. Wait, there is another possibility: perhaps we can have OCILogon use the global environment OCI(pEnv) to init the session (meaning that it uses the NLS_LANG settings), and then one can (not must) change the environment and from that moment on the new environment is used for the session. But this means we have to have a reliable switching mechanism between global and session-private environments, something I believe to be very tiresome... I would think of using the _ENV variable on logon, so you can set it right before doing OCILogon. Well, one of the other methods I can picture: 1. change in INI ini_set(); 2. Setting Local enviroment by using setlocale(). The last one looks quite elegant to me, but is only available for language charset, ENV alteraction could also help changing other data later on. What are the other DB extension's work arounds about similar things? Besides, we would then have a PHP function that can only be used with oracle 9i, whereas I would prefer to have a parameter that is only supported on such systems. Maybe just a matter of preference, but I feel that a function that is only available in certain compile situations isn't very elegant...? Better non version-depend for compiling. BTW, currently the environment is init'd in php_oci_init_globals using the OCI function OCIEnvInit, which is deprecated. We should try to switch this to the more flexible (and supported) OCIEnvCreate - just as a small note ;-) I included the patches (oci8.c and the corresponding .h) but please remember that currently you will need an Oracle 9i client to compile them (I still need to put some switches and fallback behaviours in there). I think, at this point, it is up to Thies to review the patch. -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // where PHP Begins From a developers viewpoint what I mainly did was follow Thies' proposal and put the environment struct in the session struct, and use the global env only for init work. Then I decode the character set parameter (if it is omitted, the NLS_LANG setting or Oracle default will be used) and use it in open_session. Voila, Oracle takes care of the rest. Works better than I thought :-). The only thing I need to do now is to add a compile-time decision on whether Ora9i libraries are found or not, and then to make this functionality available depending on the version. If anyone's interested I can send a patch.. Well, let's ask Thies if he wants the patch, as I have no karma to php4 anyway :) As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and No way,I meant to drop the existing compatibility :). I'd keep the existing OCI8 extension, as well as I would keep ora_* functions. I would simply add the earlier suggested oracle_* functions to be something understood as a default Oracle extension similar to the way other DBs work. That's my idea. the -1's are that someone can get confused. But, nothing is free, I think a bit of confusion is the
Re: Re: [PHP-DEV] OCI extension help offer
[EMAIL PROTECTED] schrieb am 16.10.02 14:27:35: I think, at this point, it is up to Thies to review the patch. I hope he's not too harsh on it ;-), since this code is certainly *not* ready for merging into the cvs tree. Meaning: it merges perfectly, but doesn't compile correctly on Oracle 8i systems, only on 9i - as I said, this is still on my TODO list. Abdul -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI extension help offer
[EMAIL PROTECTED] wrote... : [EMAIL PROTECTED] schrieb am 16.10.02 12:13:57: It might be interesting to change only the extension name from oci8 to oci (which would be less confusing when working with 9i). Unless your code relies on extension names, it will still work. Nice idea, but I guess this is sheer cosmetics, or do you mean to change any behaviour? Merging ... IS NOT: removing ora_* and OCI* while adding oracle_*. Nothing should be removed as that would stop many applications from continuing to work IT IS : adding a new extension which works as other DBs do (oracle_connect(), oracle_num_rows(), oracle_close() etc). Thus, one can still choose not to compile it relaying on the old extensions, or use this one as it would be the only compatible extension constantly maintained. Well, either that new extension (oracle_*) is a rewrite of the oci8 ext (working with 8+), or you are intending to target oracle 6 - 9i which I would not recommend seeing that there are *so much* differences between the versions. I think that for ora6 + 7 the current (outdated) ora_* ext is enough, and maybe we should concentrate on moving the whole thing forward. In a way its true, making Oracle 6-9 compatibility is very hard. But, it seems to me rather elegant making it. Perhaps, it would be wise to alias the oracle_* functions for ora_* functions once it is determined that Oracle version is 8. Of course we could rewrite the ext, and clean up what has grown historically, and I think this belongs into the planning for php5. I would very recommend to do so. Can't even picture PHP5 with OCI* functions instead of standard looking ones like oracle_*. This should also be the only extension to continue to work on. Currently though, we should try to consolidate the oracle support so that people have a reliable way of programming for it without having to wait too long. Well, currently these are working, no? Assuming that we are going to make a new oracle_* extension, we might also add some of the crucial developed issues into OCI8 module. This would also give us the users feedback and bugs. (Consolidation = add data type support for any missing or new types, find a solution for the lob handling (this should be easier for a script developer IMO), and introduce some useful php.ini values (maybe even for default character set?)) Agreed. Especially on datatype supports. -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // where PHP Begins -- 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
Re: [PHP-DEV] OCI extension help offer
[EMAIL PROTECTED] wrote... : [EMAIL PROTECTED] schrieb am 16.10.02 14:27:35: I think, at this point, it is up to Thies to review the patch. I hope he's not too harsh on it ;-), since this code is certainly *not* ready for merging into the cvs tree. Meaning: it merges perfectly, but doesn't compile correctly on Oracle 8i systems, only on 9i - as I said, this is still on my TODO list. Then, it should remain a patch and not a part of the distribution. Unless, it can compile safely with Oracle 8. Still, up to Thies. -- Maxim Maletsky [EMAIL PROTECTED] www.PHPBeginner.com // where PHP Begins -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend_compile.h patch
Any objections to exporting another function from zend_compile.h by applying this patch? I need this in order to compile pear/PECL/bcompiler on Windows. Edin Index: zend_compile.h === RCS file: /repository/Zend/zend_compile.h,v retrieving revision 1.144 diff -u -r1.144 zend_compile.h --- zend_compile.h 4 Aug 2002 06:39:44 - 1.144 +++ zend_compile.h 16 Oct 2002 13:35:35 - -273,7 +273,7 void zend_do_end_function_call(znode *function_name, znode *result, znode *argument_list, int is_method, int is_dynamic_fcall TSRMLS_DC); void zend_do_return(znode *expr, int do_end_vparse TSRMLS_DC); ZEND_API int do_bind_function_or_class(zend_op *opline, HashTable *function_table, HashTable *class_table, int compile_time); -void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); +ZEND_API void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); void zend_do_early_binding(TSRMLS_D); void zend_do_pass_param(znode *param, int op, int offset TSRMLS_DC); -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Multibyte ([PHP-INST] Re: If-Modified-Since..)
ply correctly to requests with If-Modified-Since: header other than to
modify PHP source code.
Try CVS version.
Thank you. The CVS version seemed to work correctly on this matter.
Hmm... Let us know the problem so that we can fix problems before
release.
What I found is as follows. Both 4.3.0-pre1 and today's CVS snapshot
reproduced the same result.
The script:
BEGIN --- test.phtml ---
?php
header ( Last-Modified: . gmdate ( 'D, d M Y H:i:s \G\M\T' ) ) ;
header(content-type: text/html; charset=ISO-2022-JP);
?
htmlheadtitleTest Multibyte/title/headbody
?php
function jstringout( $jstr )
{
print ( mb_convert_encoding( $jstr, ISO-2022-JP ) ) ;
}
jstringout ( h1 # /h1\n ) ;
?
/body/html
END --- test.phtml
If I put Japanese characters in place of #, save this script
using EUC-JP encoding, and access this script using Microsoft Internet
Explorer 6, then the characters does not seem to be correctly encoded.
The selection of encoding in the browser did not help.
In 4.2.3, this script posed no problem.
If # is replaced by the single-byte characters (alphabets) there
is no problem.
If the line:
print ( mb_convert_encoding( $jstr, ISO-2022-JP ) ) ;
in this script is modified to:
print ( mb_convert_encoding( $jstr, ISO-2022-JP, EUC-JP ) ) ;
then it works again.
Regards
Ryo
--
R Takagi [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_compile.h patch
Edin Kadribasic wrote: Any objections to exporting another function from zend_compile.h by applying this patch? I need this in order to compile pear/PECL/bcompiler on Windows. Edin actually it's not needed 'at present' cause the compiled bytecodes do not use inheritance (as the compiled bytecode includes the 'merged' view of the class'..,however - if and when I get round to writing conditional method/var class compiling, it will be needed.. Regards Alan Index: zend_compile.h === RCS file: /repository/Zend/zend_compile.h,v retrieving revision 1.144 diff -u -r1.144 zend_compile.h --- zend_compile.h 4 Aug 2002 06:39:44 - 1.144 +++ zend_compile.h 16 Oct 2002 13:35:35 - -273,7 +273,7 void zend_do_end_function_call(znode *function_name, znode *result, znode *argument_list, int is_method, int is_dynamic_fcall TSRMLS_DC); void zend_do_return(znode *expr, int do_end_vparse TSRMLS_DC); ZEND_API int do_bind_function_or_class(zend_op *opline, HashTable *function_table, HashTable *class_table, int compile_time); -void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); +ZEND_API void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); void zend_do_early_binding(TSRMLS_D); void zend_do_pass_param(znode *param, int op, int offset TSRMLS_DC); -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_compile.h patch
I get linking errors when I tried to compile it on windows. The error was that zend_do_inheritance symbol was not found. Are you saying that this call is not needed? Could it be removed then? Edin - Original Message - From: Alan Knowles [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, October 16, 2002 4:03 PM Subject: Re: [PHP-DEV] zend_compile.h patch Edin Kadribasic wrote: Any objections to exporting another function from zend_compile.h by applying this patch? I need this in order to compile pear/PECL/bcompiler on Windows. Edin actually it's not needed 'at present' cause the compiled bytecodes do not use inheritance (as the compiled bytecode includes the 'merged' view of the class'..,however - if and when I get round to writing conditional method/var class compiling, it will be needed.. Regards Alan --- - Index: zend_compile.h === RCS file: /repository/Zend/zend_compile.h,v retrieving revision 1.144 diff -u -r1.144 zend_compile.h --- zend_compile.h 4 Aug 2002 06:39:44 - 1.144 +++ zend_compile.h 16 Oct 2002 13:35:35 - @@ -273,7 +273,7 @@ void zend_do_end_function_call(znode *function_name, znode *result, znode *argument_list, int is_method, int is_dynamic_fcall TSRMLS_DC); void zend_do_return(znode *expr, int do_end_vparse TSRMLS_DC); ZEND_API int do_bind_function_or_class(zend_op *opline, HashTable *function_table, HashTable *class_table, int compile_time); -void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); +ZEND_API void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); void zend_do_early_binding(TSRMLS_D); void zend_do_pass_param(znode *param, int op, int offset TSRMLS_DC); -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_compile.h patch
Edin Kadribasic wrote: I get linking errors when I tried to compile it on windows. The error was that zend_do_inheritance symbol was not found. Are you saying that this call is not needed? Could it be removed then? At them moment, you can comment out the bcompiler_inherit call (it's never used) = however it will need including eventually... zce-parent always evaluates to NULL... Edin - Original Message - From: Alan Knowles [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, October 16, 2002 4:03 PM Subject: Re: [PHP-DEV] zend_compile.h patch Edin Kadribasic wrote: Any objections to exporting another function from zend_compile.h by applying this patch? I need this in order to compile pear/PECL/bcompiler on Windows. Edin actually it's not needed 'at present' cause the compiled bytecodes do not use inheritance (as the compiled bytecode includes the 'merged' view of the class'..,however - if and when I get round to writing conditional method/var class compiling, it will be needed.. Regards Alan --- - Index: zend_compile.h === RCS file: /repository/Zend/zend_compile.h,v retrieving revision 1.144 diff -u -r1.144 zend_compile.h --- zend_compile.h 4 Aug 2002 06:39:44 - 1.144 +++ zend_compile.h 16 Oct 2002 13:35:35 - @@ -273,7 +273,7 @@ void zend_do_end_function_call(znode *function_name, znode *result, znode *argument_list, int is_method, int is_dynamic_fcall TSRMLS_DC); void zend_do_return(znode *expr, int do_end_vparse TSRMLS_DC); ZEND_API int do_bind_function_or_class(zend_op *opline, HashTable *function_table, HashTable *class_table, int compile_time); -void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); +ZEND_API void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce); void zend_do_early_binding(TSRMLS_D); void zend_do_pass_param(znode *param, int op, int offset TSRMLS_DC); -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Plan for PHP 5.0
If someone gives me an account on an OSX box (or even better, puts an OSX box into my mailbox! ;-) I will make it work. Don't know how useful/useable this is, but Sourceforge's compile farm includes a box with OSX (10.1). - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Since the general consensus by the developers is not to remove the short_tags
or even disable them. Perhaps we should consider alternate solutions to this
problem. Given the buzzword popularity of XML and its slowly growing
popularity among website designers (XHTML) this issue is likely to come up in
the future yet again.
The solution I would like to offer, is a patch that adds special handling for
?xml. Thus preventing the language parser from attempting to parse data
inside ?xml as PHP source.
Ilia
Index: zend_language_scanner.l
===
RCS file: /repository/Zend/zend_language_scanner.l,v
retrieving revision 1.49
diff -u -3 -p -r1.49 zend_language_scanner.l
--- zend_language_scanner.l 15 Aug 2002 00:22:38 - 1.49
+++ zend_language_scanner.l 16 Oct 2002 16:07:27 -
-1194,6 +1194,14 NEWLINE (\r|\n|\r\n)
}
+INITIAL?xml{WHITESPACE} {
+ zendlval-value.str.val = (char *) estrndup(yytext, yyleng);
+ zendlval-value.str.len = yyleng;
+ zendlval-type = IS_STRING;
+ return T_INLINE_HTML;
+}
+
+
INITIAL%=|?= {
if ((yytext[1]=='%' CG(asp_tags)) || (yytext[1]=='?' CG(short_tags))) {
zendlval-value.str.val = yytext; /* no copying - intentional */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] nl2br is broken in PHP4.3.0pre1
Hi,
It seems like the nl2br() function is broken when the input string does
not contain any newlines.
[sagi@domino tmp]$ php -v
PHP 4.3.0-pre1 (cli), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
[sagi@domino tmp]$ cat test.php
?php
print nl2br('hello world').\n;
print nl2br(hello world\n).\n;
?
[sagi@domino tmp]$ php test.php
!x7
hello worldbr /
[sagi@domino tmp]$
It looks like someone already filed a bug report:
http://bugs.php.net/bug.php?id=19858
Any news about this?
Sagi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1
Hey,
this is already fixed in CVS.
thanks,
Derick
On Wed, 16 Oct 2002, Sagi Bashari wrote:
Hi,
It seems like the nl2br() function is broken when the input string does
not contain any newlines.
[sagi@domino tmp]$ php -v
PHP 4.3.0-pre1 (cli), Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies
[sagi@domino tmp]$ cat test.php
?php
print nl2br('hello world').\n;
print nl2br(hello world\n).\n;
?
[sagi@domino tmp]$ php test.php
!x7
hello worldbr /
[sagi@domino tmp]$
It looks like someone already filed a bug report:
http://bugs.php.net/bug.php?id=19858
Any news about this?
Sagi
--
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] nl2br is broken in PHP4.3.0pre1
Derick Rethans writes: Hey, this is already fixed in CVS. thanks, Derick Have you decided yet on the release cycle for 4.3? Are we any closer to branching 4.3.0 or are we going to do 4.3.0pr2 for further testing, or? :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] nl2br is broken in PHP4.3.0pre1
On Wed, 16 Oct 2002, Mike Robinson wrote: Have you decided yet on the release cycle for 4.3? Are we any closer to branching 4.3.0 or are we going to do 4.3.0pr2 for further testing, or? :) That's all up to Andrei, but I would favor for a pre2 during the next week for further testing, but it looks good so far. 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
Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1
On Wed, 16 Oct 2002, Derick Rethans wrote: That's all up to Andrei, but I would favor for a pre2 during the next week for further testing, but it looks good so far. Yes, we'll make another 'pre' release early next week. Lots of good bugs have been fixed since pre1. -Andrei http://www.gravitonic.com/ Magic 8-ball is much more powerful than we thought. I mean, back in the 70's it was predicting the nature of software in the 90's -- Outlook not so good. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Changing entity charset handling in ext/standard/html.c
Hi,
I know this may cause a potential BC problem, but I think htmlentities()
should be more consistent with mbstring modules.
The attached patch changes the behaviour of htmlentities() or its internal
counterparts, to take the character set of the characters as the value of
mbstring.internal_encoding, rather than iso-8859-1, when the charset
parameter is not specified.
And although it is not fully confirmed, this patch is also expected to fix
the phpinfo() displaying problem in multibyte environments.
Any comments are welcome.
Moriyoshi Koizumi
Index: html.c
===
RCS file: /repository/php4/ext/standard/html.c,v
retrieving revision 1.54
diff -u -r1.54 html.c
--- html.c 3 Oct 2002 12:06:52 - 1.54
+++ html.c 16 Oct 2002 20:31:01 -
-31,6 +31,11
#include langinfo.h
#endif
+#if HAVE_MBSTRING
+# include ext/mbstring/mbstring.h
+ZEND_EXTERN_MODULE_GLOBALS(mbstring)
+#endif
+
enum entity_charset { cs_terminator, cs_8859_1, cs_cp1252,
cs_8859_15, cs_utf_8, cs_big5, cs_gb2312,
cs_big5hkscs, cs_sjis, cs_eucjp};
-520,9 +525,45
enum entity_charset charset = cs_8859_1;
int len = 0;
+#if HAVE_MBSTRING
+ /* XXX: Ugly things. Why don't we look for a more sophisticated way? */
+ if (charset_hint == NULL) {
+ switch (MBSTRG(internal_encoding)) {
+ case mbfl_no_encoding_utf8:
+ return cs_utf_8;
+
+ case mbfl_no_encoding_euc_jp:
+ case mbfl_no_encoding_eucjp_win:
+ return cs_eucjp;
+
+ case mbfl_no_encoding_sjis:
+ case mbfl_no_encoding_sjis_win:
+ case mbfl_no_encoding_sjis_mac:
+ return cs_sjis;
+
+ case mbfl_no_encoding_cp1252:
+ return cs_cp1252;
+
+ case mbfl_no_encoding_8859_15:
+ return cs_8859_15;
+
+ case mbfl_no_encoding_big5:
+ return cs_big5;
+
+ case mbfl_no_encoding_euc_cn:
+ case mbfl_no_encoding_hz:
+ case mbfl_no_encoding_cp936:
+ return cs_gb2312;
+
+ default:
+ return cs_8859_1;
+ }
+ }
+#else
/* Guarantee default behaviour for backwards compatibility */
if (charset_hint == NULL)
return cs_8859_1;
+#endif
if (strlen(charset_hint) == 0) {
/* try to detect the charset for the locale */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handling inext/standard/html.c
Unfortunately, we absolutely must remain 100% backwards compatible with htmlentities(), so this patch should not be applied. However, I don't see a problem with making phpinfo determine the charset and passing that on to the internal htmlentities function? --Wez. On Thu, 17 Oct 2002, Moriyoshi Koizumi wrote: Hi, I know this may cause a potential BC problem, but I think htmlentities() should be more consistent with mbstring modules. The attached patch changes the behaviour of htmlentities() or its internal counterparts, to take the character set of the characters as the value of mbstring.internal_encoding, rather than iso-8859-1, when the charset parameter is not specified. And although it is not fully confirmed, this patch is also expected to fix the phpinfo() displaying problem in multibyte environments. Any comments are welcome. Moriyoshi Koizumi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handling inext/standard/html.c
Wez Furlong [EMAIL PROTECTED] wrote: Unfortunately, we absolutely must remain 100% backwards compatible with htmlentities(), so this patch should not be applied. Were there any discussions exactly about this issue? Though I have to see some historical reason, however I don't understand why 100% backwards compatibility is required for htmlentities(). Because the patched htmlentities() acts in the same way with default configuration, and IMHO defaulting to iso-8859-1 is quite meaningless for the scripts that uses other charsets than it. Hmm... otherwise I would like to suggest a mbstring function like mb_htmlentities(), but it would sound like a reinvention of the same wheel... However, I don't see a problem with making phpinfo determine the charset and passing that on to the internal htmlentities function? The problem is that php_info_html_esc() in ext/standard/info.c calls php_escape_html_entities() with no charset information specified. Without the patch, every character is treated as ISO-8859-1 even if a fetched character is actually a mere first byte of a multibyte character. Moriyoshi Koizumi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
On Wed, 16 Oct 2002, Derick Rethans wrote: On Wed, 16 Oct 2002, Markus Fischer wrote: On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : While I think it is a bit unintuitive to have $_FILES separate like it is (rather than a part of $_POST, for example), I think it would be much worse to also separate it from $_REQUEST. After all, as Sterling pointed out, it is part of the request. It makes quite sense to me that _FILES is separate. It is much easier that way to iterate through multiple uploaded files without much hassle. Another good point to keep them seperate :) But of course that whould have been possible anyway, wheter it's possible to access ot from the $_REQUEST hash or not.. I actually thought that $_FILES wasn't part of $_REQUEST before that bug report came in.. And it's not separate from EGPCS btw. (php.ini: variables_order) Which one controls it? P? :) And I think import_request_variables() doesn't work either for those.. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?
On Thu, 17 Oct 2002, Jani Taskinen wrote: On Wed, 16 Oct 2002, Derick Rethans wrote: On Wed, 16 Oct 2002, Markus Fischer wrote: On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : While I think it is a bit unintuitive to have $_FILES separate like it is (rather than a part of $_POST, for example), I think it would be much worse to also separate it from $_REQUEST. After all, as Sterling pointed out, it is part of the request. It makes quite sense to me that _FILES is separate. It is much easier that way to iterate through multiple uploaded files without much hassle. Another good point to keep them seperate :) But of course that whould have been possible anyway, wheter it's possible to access ot from the $_REQUEST hash or not.. I actually thought that $_FILES wasn't part of $_REQUEST before that bug report came in.. And it's not separate from EGPCS btw. (php.ini: variables_order) Which one controls it? P? :) And I think import_request_variables() doesn't work either for those.. Should read the manual more often..it does support FILES too. :I (dunno if it actually works though, haven't tested it) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handling inext/standard/html.c
Search the archives for the discussion. phpinfo could determine the charset as your patch does at the start, and then pass the info in php_escape_html_entities. Seems easy to me. --Wez. On 10/16/02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote: Wez Furlong [EMAIL PROTECTED] wrote: Unfortunately, we absolutely must remain 100% backwards compatible with htmlentities(), so this patch should not be applied. Were there any discussions exactly about this issue? Though I have to see some historical reason, however I don't understand why 100% backwards compatibility is required for htmlentities(). Because the patched htmlentities() acts in the same way with default configuration, and IMHO defaulting to iso-8859-1 is quite meaningless for the scripts that uses other charsets than it. Hmm... otherwise I would like to suggest a mbstring function like mb_htmlentities(), but it would sound like a reinvention of the same wheel... However, I don't see a problem with making phpinfo determine the charset and passing that on to the internal htmlentities function? The problem is that php_info_html_esc() in ext/standard/info.c calls php_escape_html_entities() with no charset information specified. Without the patch, every character is treated as ISO-8859-1 even if a fetched character is actually a mere first byte of a multibyte character. Moriyoshi Koizumi -- 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
Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1
On Wed, 16 Oct 2002, Andrei Zmievski wrote: On Wed, 16 Oct 2002, Derick Rethans wrote: That's all up to Andrei, but I would favor for a pre2 during the next week for further testing, but it looks good so far. Yes, we'll make another 'pre' release early next week. Lots of good bugs have been fixed since pre1. Just wondering..but what is a 'good bug' ? IMO, every bug is BAD. :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Xerces?
Hi all, I have done limited looking but as far as I can tell Xerces is not supported by PHP. A) hopefully I am wrong and just didn't look hard enough. B) If not, any validating parsers that are supported that do DTD validation? It looks like there's an experimental Xalan ext out there, but no Xerces. I have a vague memory of the XML setup being generalized to allow (x) parsers, did that happen, etc? In any case, if there aren't any validating parsers supported by PHP... There should be :) Please respond to the binarycloud-dev list also... Thanks, _alex -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Xerces?
There is only Sablotron support. No Xerces. Feel free to contribute the code to support Xerces. -Rasmus On Wed, 16 Oct 2002, Alex Black wrote: Hi all, I have done limited looking but as far as I can tell Xerces is not supported by PHP. A) hopefully I am wrong and just didn't look hard enough. B) If not, any validating parsers that are supported that do DTD validation? It looks like there's an experimental Xalan ext out there, but no Xerces. I have a vague memory of the XML setup being generalized to allow (x) parsers, did that happen, etc? In any case, if there aren't any validating parsers supported by PHP... There should be :) Please respond to the binarycloud-dev list also... Thanks, _alex -- 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
Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1
Jani Taskinen [EMAIL PROTECTED] wrote: Just wondering..but what is a 'good bug' ? IMO, every bug is BAD. :) evil ones :) -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [binarycloud-dev] Re: [PHP-DEV] Xerces?
There is only Sablotron support. No Xerces. Feel free to contribute the code to support Xerces. hi Rasmus, Sab is an XSLT processor, Xerces is a validating XML parser. You were probably thinking Xalan, which is the apachexml XSLT processor. Yes, I'd also like to have access to Xalan via php, though I haven't used it, so I don't know if it's cool. Probably is. Sab ceartainly leaves a lot to be desired :) My question was: what's the status on all of the xml/xslt extension stuff? I.e. Has the xml parser extension been changed to be more general so an extension can happen? I know little of those goings-on, just that there was some discussion. Do you guys know of anyone who is working on Xerces or Xalan support? Etc. Thanks, _alex -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Xerces?
Since Xalan is written java, won't ext/java do that work anyway? On Wed, Oct 16, 2002 at 02:56:50PM -0700, Alex Black wrote : Hi all, I have done limited looking but as far as I can tell Xerces is not supported by PHP. A) hopefully I am wrong and just didn't look hard enough. B) If not, any validating parsers that are supported that do DTD validation? It looks like there's an experimental Xalan ext out there, but no Xerces. I have a vague memory of the XML setup being generalized to allow (x) parsers, did that happen, etc? In any case, if there aren't any validating parsers supported by PHP... There should be :) Please respond to the binarycloud-dev list also... Thanks, _alex -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc rei_ Derick, while ($xml) $ass-get_new_ideas(); [James] Markus: IE on_user_fart() -- People doesn't seem to like the new XHTML2 specs :) -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Xerces?
Has anyone started any work work on this? On Wednesday, October 16, 2002, at 05:59 PM, Rasmus Lerdorf wrote: There is only Sablotron support. No Xerces. Feel free to contribute the code to support Xerces. -Rasmus On Wed, 16 Oct 2002, Alex Black wrote: Hi all, I have done limited looking but as far as I can tell Xerces is not supported by PHP. A) hopefully I am wrong and just didn't look hard enough. B) If not, any validating parsers that are supported that do DTD validation? It looks like there's an experimental Xalan ext out there, but no Xerces. I have a vague memory of the XML setup being generalized to allow (x) parsers, did that happen, etc? In any case, if there aren't any validating parsers supported by PHP... There should be :) Please respond to the binarycloud-dev list also... Thanks, _alex -- 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 // George Schlossnagle // Principal Consultant // OmniTI, Inc http://www.omniti.com // (c) 240.460.5234 (e) [EMAIL PROTECTED] // 1024D/1100A5A0 1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Xerces?
Xalan and Xerces have both java and c versions. Markus Fischer wrote: Since Xalan is written java, won't ext/java do that work anyway? On Wed, Oct 16, 2002 at 02:56:50PM -0700, Alex Black wrote : Hi all, I have done limited looking but as far as I can tell Xerces is not supported by PHP. A) hopefully I am wrong and just didn't look hard enough. B) If not, any validating parsers that are supported that do DTD validation? It looks like there's an experimental Xalan ext out there, but no Xerces. I have a vague memory of the XML setup being generalized to allow (x) parsers, did that happen, etc? In any case, if there aren't any validating parsers supported by PHP... There should be :) Please respond to the binarycloud-dev list also... Thanks, _alex -- 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: Multibyte ([PHP-INST] Re: If-Modified-Since..)
Ryo Takagi wrote: If the line: print ( mb_convert_encoding( $jstr, ISO-2022-JP ) ) ; in this script is modified to: print ( mb_convert_encoding( $jstr, ISO-2022-JP, EUC-JP ) ) ; then it works again. This cannot be fixed. Check modify your detect order by mb_detect_order(). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Multibyte ([PHP-INST] Re: If-Modified-Since..)
Forgot to what it's doing. Since the multibyte char sequence is too short, mbstring is failing to detect encoding correctly. In this case, we can specify encoding or modify detect order. -- Yasuo Ohgaki Yasuo Ohgaki wrote: Ryo Takagi wrote: If the line: print ( mb_convert_encoding( $jstr, ISO-2022-JP ) ) ; in this script is modified to: print ( mb_convert_encoding( $jstr, ISO-2022-JP, EUC-JP ) ) ; then it works again. This cannot be fixed. Check modify your detect order by mb_detect_order(). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Xerces?
Since Xalan is written java, won't ext/java do that work anyway? Sorta, That's a little funky but yes it would work. I would far prefer to have a c-extension for the C++ version. My (limited) experience with php/java is... Slightly funk. It does work but it seems ornry :) Still no one has told me what's happening with the XML extension! :) That's all I wanted to know... _a -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Multibyte ([PHP-INST] Re: If-Modified-Since..)
nah... If it(==from_encoding) is not specified, the internal encoding will be used. (http://jp.php.net/manual/en/function.mb-convert-encoding.php) so it's just because mbstring.internal_encoding is not properly set? Masaki Fujimoto On Thu, 17 Oct 2002 08:17:27 +0900 Yasuo Ohgaki [EMAIL PROTECTED] wrote: Forgot to what it's doing. Since the multibyte char sequence is too short, mbstring is failing to detect encoding correctly. In this case, we can specify encoding or modify detect order. -- Yasuo Ohgaki Yasuo Ohgaki wrote: Ryo Takagi wrote: If the line: print ( mb_convert_encoding( $jstr, ISO-2022-JP ) ) ; in this script is modified to: print ( mb_convert_encoding( $jstr, ISO-2022-JP, EUC-JP ) ) ; then it works again. This cannot be fixed. Check modify your detect order by mb_detect_order(). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Ilia A. wrote: Since the general consensus by the developers is not to remove the short_tags or even disable them. Perhaps we should consider alternate solutions to this problem. Given the buzzword popularity of XML and its slowly growing popularity among website designers (XHTML) this issue is likely to come up in the future yet again. The solution I would like to offer, is a patch that adds special handling for ?xml. Thus preventing the language parser from attempting to parse data inside ?xml as PHP source. I think it's reasonable patch, but ? is XML Processing Instruction tag... We never know how many processing tags will be in the future. We don't know if there will be xml processor that processes php tag or not. Therefore, user should turn short tag off by themselves if the want to use XML, or echo ?xml .. at the beginning of output. IMO, disabling short tag in php.ini-recommended is ok in the future. I know Zeev don't like it and I understand the reasoning. :) Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; == ;If you are willing to process XML file with PHP, you should ;turn short tag off or echo XML processing tag, ? whenever ;needed. Turning off this directive and use of ?php is generally ;recommended with XML documents. ; ;!!CAUTION!! If you have a script start with short tag and short_open_tag=Off, ; ?, the content(source) is displayed!! In future version of ;php.ini-recommended will have short_open_tag=Off by default! Use of short ;open tag is discouraged. ; ;NOTE: Authors writing portable scripts should check this ini setting. ;or echo ?. short_open_tag=On == -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
IMHO, i think that short tags should be taken out of php and just use the ?php to start the parser. if a patch is added then the parser just has more to look out for. What is the XML standard changes to something else. We cannot see what is coming next. But if short_open_tags is turned off by default then that might solve the majority of the problem. However, i think that the solution lies in removing the short tag and not adding a patch to the parser. On Wed, 2002-10-16 at 20:18, Yasuo Ohgaki wrote: Ilia A. wrote: Since the general consensus by the developers is not to remove the short_tags or even disable them. Perhaps we should consider alternate solutions to this problem. Given the buzzword popularity of XML and its slowly growing popularity among website designers (XHTML) this issue is likely to come up in the future yet again. The solution I would like to offer, is a patch that adds special handling for ?xml. Thus preventing the language parser from attempting to parse data inside ?xml as PHP source. I think it's reasonable patch, but ? is XML Processing Instruction tag... We never know how many processing tags will be in the future. We don't know if there will be xml processor that processes php tag or not. Therefore, user should turn short tag off by themselves if the want to use XML, or echo ?xml .. at the beginning of output. IMO, disabling short tag in php.ini-recommended is ok in the future. I know Zeev don't like it and I understand the reasoning. :) Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; == ;If you are willing to process XML file with PHP, you should ;turn short tag off or echo XML processing tag, ? whenever ;needed. Turning off this directive and use of ?php is generally ;recommended with XML documents. ; ;!!CAUTION!! If you have a script start with short tag and short_open_tag=Off, ; ?, the content(source) is displayed!! In future version of ;php.ini-recommended will have short_open_tag=Off by default! Use of short ;open tag is discouraged. ; ;NOTE: Authors writing portable scripts should check this ini setting. ;or echo ?. short_open_tag=On == -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- S RAY HUNTER email: [EMAIL PROTECTED] email: [EMAIL PROTECTED] www:http://venticon.com -- .: B i g D o g :. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On October 16, 2002 10:18 pm, Yasuo Ohgaki wrote: Ilia A. wrote: Since the general consensus by the developers is not to remove the short_tags or even disable them. Perhaps we should consider alternate solutions to this problem. Given the buzzword popularity of XML and its slowly growing popularity among website designers (XHTML) this issue is likely to come up in the future yet again. The solution I would like to offer, is a patch that adds special handling for ?xml. Thus preventing the language parser from attempting to parse data inside ?xml as PHP source. I think it's reasonable patch, but ? is XML Processing Instruction tag... We never know how many processing tags will be in the future. We don't know if there will be xml processor that processes php tag or not. Therefore, user should turn short tag off by themselves if the want to use XML, or echo ?xml .. at the beginning of output. Yes sure, but as these discussions, which are starting to appear with ever increasing frequency that is simply not the case. There are numerous reasons for this many of which have been covered in various discussion on this topic. IMO, disabling short tag in php.ini-recommended is ok in the future. I know Zeev don't like it and I understand the reasoning. :) Maybe I am wrong, but judging from the feedback given by various developers this is unlikely to happen even in PHP 5.0. Thus, I think we must consider how to address this problem via other means. Unless we can solve this issue, then we return to this discussion again and again. Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handling
Wez Furlong wrote: Search the archives for the discussion. phpinfo could determine the charset as your patch does at the start, phpinfo() better not to detect charsets, since user are using it to see variables' values. i.e. Variables may contains different encoding var to var. Applying htmlentities() to phpinfo() output prevents ability to change encoding on users(browser) side. Besides phpinfo() issue, I'm +1 for the patch. It shouldn't break compatibility, since converting chars to entities with different encoding does not work/make sense or I must be missing some. BTW, we're better to have PHPAPI function returns internal encoding, rather than switch(). -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Multibyte ([PHP-INST] Re: If-Modified-Since..)
Masaki Fujimoto wrote: nah... If it(==from_encoding) is not specified, the internal encoding will be used. (http://jp.php.net/manual/en/function.mb-convert-encoding.php) so it's just because mbstring.internal_encoding is not properly set? Thanks for heads up. I made the same mistake several times even if I wrote english version of the manual page. Guessing encoding every time is stupid :) You should have wrong internal_encoding. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Ilia A. wrote: Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. We should have warned people not to use short tags years ago. We can try it from now. Until we get rid of short tag or disable it by default, we suggest users to work around problem. echo ?xml ..? works always and authors of portable scripts should use it. If there are new processing tags, echo ?new_xml_PI .? instead of adding new PI to parser. (We never know if user use custom PI tag or not) IMHO, it's good enough work around until we have PHP6 or later. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On October 16, 2002 11:11 pm, Yasuo Ohgaki wrote: Ilia A. wrote: Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. We should have warned people not to use short tags years ago. What happened in the past is in the past, lets concentrate on the future. We can try it from now. Until we get rid of short tag or disable it by default, we suggest users to work around problem. echo ?xml ..? works always and authors of portable scripts should use it. If there are new processing tags, echo ?new_xml_PI .? instead of adding new PI to parser. (We never know if user use custom PI tag or not) I think that we can say with a fair degree of certainty ?xml will remain as is. No one will want to change for BC reasons ;). I find it even less likely that we'd drop short tags when PHP6 comes around because they'll be even more users using them then there are now (assuming php usage increases). For most people it is easier to use ? then ?php and since it works just about everywhere it is 'safe' to do, at least as far as they know. It is also to easier to remember, especially for newbies, which imho is the most common reasons people use them. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
We had the same discussion. I brought it up last time. There were patch for ?xml just like yours. The outcome was modified manual page that discourages use of short tag for portable script. http://www.php.net/manual/en/language.basic-syntax.php Current php.ini-dist has == ; Allow the ? tag. Otherwise, only ?php and script tags are recognized. short_open_tag = On == Adding appropriate comment is better than adding token to language. i.e. compatibility between new and old PHP. The best way to go is discourage use of short tag whenever possible, change default few years later, IMHO. Even if we never change the default, ?php echo ?xml ..?;? works always w/o patch. -- Yasuo Ohgaki Ilia A. wrote: On October 16, 2002 11:11 pm, Yasuo Ohgaki wrote: Ilia A. wrote: Isn't BIG caution for short_open_tag=Off while having short_open_tag=On enough for now? Something like; Nope, please consider a hosting enviroment where an average user does not even have access to the php.ini file. In fact, most ISP won't make user's life difficult by forcing ?php because they know that'll lead to waste of their time and money since they'll be forced to deal with user complains about why their PHP scripts are not working. Even people with the ability to modify this file will not necessarily edit it and only do so if they need to change an option not changeable via other means. We should have warned people not to use short tags years ago. What happened in the past is in the past, lets concentrate on the future. We can try it from now. Until we get rid of short tag or disable it by default, we suggest users to work around problem. echo ?xml ..? works always and authors of portable scripts should use it. If there are new processing tags, echo ?new_xml_PI .? instead of adding new PI to parser. (We never know if user use custom PI tag or not) I think that we can say with a fair degree of certainty ?xml will remain as is. No one will want to change for BC reasons ;). I find it even less likely that we'd drop short tags when PHP6 comes around because they'll be even more users using them then there are now (assuming php usage increases). For most people it is easier to use ? then ?php and since it works just about everywhere it is 'safe' to do, at least as far as they know. It is also to easier to remember, especially for newbies, which imho is the most common reasons people use them. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
On October 16, 2002 11:46 pm, Yasuo Ohgaki wrote: We had the same discussion. I brought it up last time. There were patch for ?xml just like yours. The outcome was modified manual page that discourages use of short tag for portable script. http://www.php.net/manual/en/language.basic-syntax.php Given the fact we are carrying this conversation again, implies the original solution did not solve the problem, no? Current php.ini-dist has ==but what about all the people who for whatever reason make their PHP parse all pages, even .html ones ; Allow the ? tag. Otherwise, only ?php and script tags are recognized. short_open_tag = On == Adding appropriate comment is better than adding token to language. i.e. compatibility between new and old PHP. I am not saying that the proposed patch is the best solution to the problem, there may very well be other, better solutions. However, I personally, do not see such solutions being presented. All the solutions either involve breaking of BC, which most people do not wish to do, or ignoring the issue and hoping that eventually people will switch. The best way to go is discourage use of short tag whenever possible, change default few years later, IMHO. Even if we never change the default, ?php echo ?xml ..?;? works always w/o patch. Yes, that works, but what about all the people who for whatever reason make their PHP parse all pages, even .html ones. On such a server if someone places an XML (XHTML) document, won't they be surprised by the parse errors they get. This person may not even know PHP exists and yet they would get PHP errors. No amount of documentation will solve this sort of a problem and this is just one example, there are more. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zip extension fixes (cause it's totally borked :)
attached fixes should enable the zip extension to a) build, b) build as
a module
want to give me Karma (or patch it in)
Regards
Alan
? .libs
? Makefile
? Makefile.fragments
? Makefile.global
? Makefile.objects
? acinclude.m4
? aclocal.m4
? autom4te.cache
? build
? config.cache
? config.guess
? config.h
? config.h.in
? config.log
? config.nice
? config.status
? config.sub
? configure
? configure.in
? include
? install-sh
? libtool
? ltmain.sh
? missing
? mkinstalldirs
? modules
? scan_makefile_in.awk
? zipfix.diff
Index: config.m4
===
RCS file: /repository/php4/ext/zip/config.m4,v
retrieving revision 1.4
diff -u -r1.4 config.m4
--- config.m4 12 Mar 2002 16:39:16 - 1.4
+++ config.m4 17 Oct 2002 04:20:04 -
-6,8 +6,7
[ --with-zip[=DIR]Include ZIP support (requires zziplib = 0.10.6).])
if test $PHP_ZIP != no; then
- PHP_NEW_EXTENSION(zip, zip.c, $ext_shared)
- for i in $PHP_ZIP /usr/local /usr ; do
+ for i in $PHP_ZIP /usr/local /usr ; do
if test -f $i/include/zzlib/zziplib.h; then
ZZIPLIB_DIR=$i
ZZIPLIB_INCDIR=$i/include/zzlib
-23,15 +22,13
ZZIPLIB_LIBDIR=$ZZIPLIB_DIR/lib
- PHP_TEMP_LDFLAGS(-L$ZZIPLIB_LIBDIR,[
- AC_CHECK_LIB(zzip, zzip_open, [AC_DEFINE(HAVE_ZZIPLIB,1,[ ])],
-[AC_MSG_ERROR(zziplib module requires zzlib = 0.10.6.)])
- ])
+
+ PHP_ADD_INCLUDE($ZZIPLIB_INCDIR)
PHP_SUBST(ZIP_SHARED_LIBADD)
PHP_ADD_LIBRARY_WITH_PATH(zzip, $ZZIPLIB_LIBDIR, ZIP_SHARED_LIBADD)
-
- PHP_ADD_INCLUDE($ZZIPLIB_INCDIR)
+ AC_CHECK_LIB(zzip, zzip_open, [AC_DEFINE(HAVE_ZZIPLIB,1,[ ])],
+[AC_MSG_ERROR(zziplib module requires zzlib = 0.10.6.)],)
- PHP_FOPENCOOKIE
+ PHP_NEW_EXTENSION(zip, zip.c, $ext_shared)
+
fi
Index: php_zip.h
===
RCS file: /repository/php4/ext/zip/php_zip.h,v
retrieving revision 1.7
diff -u -r1.7 php_zip.h
--- php_zip.h 11 May 2002 02:12:44 - 1.7
+++ php_zip.h 17 Oct 2002 04:20:05 -
-27,15 +27,23
#define phpext_zip_ptr zip_module_entry
#define PHP_ZZIPLIB_API
+
+
#ifdef PHP_WIN32
+
#undef PHP_ZZIPLIB_API
#ifdef ZIP_EXPORTS
#define PHP_ZZIPLIB_API __declspec(dllexport)
#else
#define PHP_ZZIPLIB_API __declspec(dllimport)
#endif
+
#endif
+#ifdef ZTS
+#include TSRM.h
+#endif
+
PHP_MINIT_FUNCTION(zip);
PHP_MINFO_FUNCTION(zip);
-59,7 +67,7
#define phpext_zziplib_ptr NULL
#endif
-#endif /* PHP_ZZIPLIB_H */
+#endif /* PHP_ZLIB_H */
/*
Index: zip.c
===
RCS file: /repository/php4/ext/zip/zip.c,v
retrieving revision 1.32
diff -u -r1.32 zip.c
--- zip.c 20 May 2002 18:33:08 - 1.32
+++ zip.c 17 Oct 2002 04:20:05 -
-17,11 +17,13
*/
/* $Id: zip.c,v 1.32 2002/05/20 18:33:08 mfischer Exp $ */
-
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
#include php.h
#include php_ini.h
#include php_zip.h
-
+
#if HAVE_ZZIPLIB
#include ext/standard/info.h
-56,15 +58,15
/* {{{ zip_module_entry
*/
zend_module_entry zip_module_entry = {
-STANDARD_MODULE_HEADER,
+ STANDARD_MODULE_HEADER,
zip,
zip_functions,
PHP_MINIT(zip),
NULL,
NULL,
- NULL,
+ NULL,
PHP_MINFO(zip),
-NO_VERSION_YET,
+ NO_VERSION_YET,
STANDARD_MODULE_PROPERTIES
};
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Ilia A. wrote: We should have warned people not to use short tags years ago. What happened in the past is in the past, lets concentrate on the future. Sure. We should. The best way to go is discourage use of short tag whenever possible, change default few years later, IMHO. Even if we never change the default, ?php echo ?xml ..?;? works always w/o patch. Yes, that works, but what about all the people who for whatever reason make their PHP parse all pages, even .html ones. On such a server if someone places an XML (XHTML) document, won't they be surprised by the parse errors they get. This person may not even know PHP exists and yet they would get PHP errors. No amount of documentation will solve this sort of a problem and this is just one example, there are more. This is one of the reason why I think we should try to change short_open_tag default. ? is reserved for XML PI (Processing Instruction). There may be many (and/or custom) PI tags and it may become more serious problem in the future. We may even have XML processor that processes PHP code in XML documents in the future. i.e. PHP interpreter is invoked from XML processor. Fortunately, we don't have much problem now. I think we are better to start discourage use of short tag more loudly instead of work around one by one. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c
Yep, as far as I read the archives, I haven't found any discussions on the charset related backwards problems. So I wrote *exactly* about this issue. You may want to redirect me to bug #9392 (http://bugs.php.net/bug.php?id=9392), but it doens't seem to help... In addition, I found determining the internal charset by LC_CTYPE is dangerous because setlocale() is not thread-safe in some libc implementations (glibc seems to be that one). I'm going to read archives more carefully, though I think even handling the charset in phpinfo() will yield the same discussion in the future. Moriyoshi Koizumi Wez Furlong [EMAIL PROTECTED] wrote: Search the archives for the discussion. phpinfo could determine the charset as your patch does at the start, and then pass the info in php_escape_html_entities. Seems easy to me. --Wez. On 10/16/02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote: Wez Furlong [EMAIL PROTECTED] wrote: Unfortunately, we absolutely must remain 100% backwards compatible with htmlentities(), so this patch should not be applied. Were there any discussions exactly about this issue? Though I have to see some historical reason, however I don't understand why 100% backwards compatibility is required for htmlentities(). Because the patched htmlentities() acts in the same way with default configuration, and IMHO defaulting to iso-8859-1 is quite meaningless for the scripts that uses other charsets than it. Hmm... otherwise I would like to suggest a mbstring function like mb_htmlentities(), but it would sound like a reinvention of the same wheel... However, I don't see a problem with making phpinfo determine the charset and passing that on to the internal htmlentities function? The problem is that php_info_html_esc() in ext/standard/info.c calls php_escape_html_entities() with no charset information specified. Without the patch, every character is treated as ISO-8859-1 even if a fetched character is actually a mere first byte of a multibyte character. Moriyoshi Koizumi -- 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
