Re[2]: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

DR> There were some, for example Sascha's addition. This alone would qualify DR> a full QA, and not a short and fast one. Our general idea was to NOT add DR> new code to release branches, but at the moment developers are still DR> doing this because *they* need a new function and dont want to wai

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

On Wed, 15 Jan 2003, Edin Kadribasic wrote: > > Maybe I misunderstood when Edin said that there will be no new release > > for some time due to the move on PHP 5. > > Yes, you misunderstood what I said which was that there is not going to be a > release from the HEAD branch for some time to come

RE: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

> you're propably a bit too optimistic, i can hardly imagine that all existing > extensions all over the world compile out of the box against ZE2. i guess only > a handful do this. Apparently, most of the extensions PHP ships with seem to work out of the box. I'm under the impression that

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

> > Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not > > favoring new code going into the PHP_4_3 branch, but only bugfixes. I'd > > like to see new functionality going into HEAD, for PHP 5. > > You might favor that, but I don't pretend that PHP 5.x will > become use

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

On Wed, 15 Jan 2003, Derick Rethans wrote: > On Wed, 15 Jan 2003, Christoph Grottolo wrote: > > > So why not release a bugfix 4.3.1 not because of a security hole but > > just to complete the great work already done on PHP 4.3 - before > > definitely jumping to PHP 5? > > Who said that we're not g

Re: [PHP-DEV] request data filter

> You could have your custom C extension be called as one of the hooks. I suppose I could munge with the apache tables directly in a hook before the data is read by the standard treat_data hook, although for post data I am not sure I have any way to get in there before the ap_get_client_block() ca

Re: [PHP-DEV] request data filter

You could have your custom C extension be called as one of the hooks. On Wednesday, January 15, 2003, at 09:42 PM, Rasmus Lerdorf wrote: On Wed, 15 Jan 2003, George Schlossnagle wrote: You consider running the apache_hooks code? This should be simple there. You mean do the filtering straig

Re: [PHP-DEV] request data filter

On Wed, 15 Jan 2003, George Schlossnagle wrote: > You consider running the apache_hooks code? This should be simple > there. You mean do the filtering straight from a PHP script that gets called from a hook? That's a lot of looping through a bunch of arrays. This has to happen on every requ

Re: [PHP-DEV] request data filter

You consider running the apache_hooks code? This should be simple there. -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] request data filter

In trying to implement a security policy I need to pass all user-supplied data (GET/POST/Cookie) through a filter function which implements this security. This isn't all that hard to implement as an extension through new 4.3 treat_data and post_handler hooks, however it gets messy when you throw m

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

> Maybe I misunderstood when Edin said that there will be no new release > for some time due to the move on PHP 5. Yes, you misunderstood what I said which was that there is not going to be a release from the HEAD branch for some time to come -- until PHP 5 is released. As a matter of fact I thin

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

[EMAIL PROTECTED] (Derick Rethans) wrote: >> So why not release a bugfix 4.3.1 not because of a security hole but >> just to complete the great work already done on PHP 4.3 - before >> definitely jumping to PHP 5? > >Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not >favorin

Re: [PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

On Wed, 15 Jan 2003, Christoph Grottolo wrote: > So why not release a bugfix 4.3.1 not because of a security hole but > just to complete the great work already done on PHP 4.3 - before > definitely jumping to PHP 5? Who said that we're not going to release a 4.3.1 or 4.3.n? I'm just not favoring

Re: [PHP-DEV] Re: [Fwd: 4.3.0 w/ Sablotron version check problem]

That's because -lpng was compiled with gcc2, because the config.log showed an error in -lpng and barfed on the first C++ extension. See his config.log at: http://www.theapotek.com/teknotes/config.log.txt At 22:07 1/15/2003, J Smith wrote: >> And here's my error output during config: >> checking

[PHP-DEV] 4.3.1 (was: [PHP-CVS] cvs: php4(PHP_4_3) /main SAPI.h)

[EMAIL PROTECTED] (Sascha Schumann) wrote: >And we should not close our eyes from the possibility of a >4.3.1 release (e.g. due to a security issue). In that >not-so-remote event, having a 4.3 branch with minimal changes >is a simple requirement. With 4.3.0 you introduced lots of

[PHP-DEV] Re: [Fwd: 4.3.0 w/ Sablotron version check problem]

Just saw this in the weekly php.dev summary on Zend.com. Sablotron is working fine for me. >From phpinfo(): XSLT - support enabled Backend - Sablotron Sablotron Version - 0.97 Sablotron Information - Cflags: -g -O2 Libs: -L/usr/local/lib -lexpat Prefix: /usr/local Details: linux (kernel

Re: [PHP-DEV] [Win32] Install Problems....

I already tried some of these snaps but don't work for me. Everytime i try to run a php-script windows tells me that PHP has generated errors and was closed. In addition: I wrote i got a version running from CVS, this was using Linux not Windows :( - Original Message - From: "Xavier Spr

Re: [PHP-DEV] [Win32] Install Problems....

You'll find the latest development snapshot on http://snaps.php.net On Wed, 2003-01-15 at 14:24, Red Wingate wrote: > don't know where i can get a stable version. > > Enviroment: > Win2000 SP3 with Apache 2.0.43 > > --- Red Wingate > > p.s: plz dont flame about my english :) -- Xavier S

RE: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

> From: Sascha Schumann [mailto:[EMAIL PROTECTED]] > > > iirc the reason why i changed it to unsigned was that > actually the zend engine > > treated it as unsigned everywhere but in that particular > struct. i also > > remember that i discussed that with andi and that he agreed > to change th

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

On Wed, 15 Jan 2003, Harald Radi wrote: > iirc the reason why i changed it to unsigned was that actually the zend engine > treated it as unsigned everywhere but in that particular struct. i also > remember that i discussed that with andi and that he agreed to change this in > the ze2 cvs module an

[PHP-DEV] [Win32] Install Problems....

I ran in serious troubles trying to install a recent version of PHP compiled with the Zend Engine 2. I have the latest release of Apache2 installed and running a PHP Snapshot as CGI always ends in a crash (PHP not Windows) I was able to install a recent CVS version of 4.3.0 with the Zend Engine 2

[PHP-DEV] CVS Account Request: sil

Translating the documentation (English to Italian) -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

On Wed, Jan 15, 2003 at 06:36:20PM +0100, Harald Radi wrote: > iirc the reason why i changed it to unsigned was that actually the zend engine > treated it as unsigned everywhere but in that particular struct. i also > remember that i discussed that with andi and that he agreed to change this in > t

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

iirc the reason why i changed it to unsigned was that actually the zend engine treated it as unsigned everywhere but in that particular struct. i also remember that i discussed that with andi and that he agreed to change this in the ze2 cvs module and that the extensions should be *fixed*. i agree

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

Ilia A. wrote: On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of "NotAPHPBug"? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not a

RE: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)

On Wed, 15 Jan 2003, Ford, Mike [LSS] wrote: > > Two exactly the same bugs were posted one minute after eachother > > from persons on the same domain. > > (Grits teeth) But it's still a duplicate report! No, it was merely a co-worker which wanted to focus more attention on the bug

RE: [PHP-DEV] Re: #21659 [Com]: sprintf

> From: Ilia A. [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 15, 2003 11:19 AM > > Consider the following, there are a lot more PHP users then PHP > developers and > considering that not all PHP developers are actively involved in the bug > solving process (many are involved with PEAR/PECL

RE: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)

> -Original Message- > From: Derick Rethans [mailto:[EMAIL PROTECTED]] > Sent: 15 January 2003 15:17 > To: [EMAIL PROTECTED] > Cc: PHP Quality Assurance Team Mailing List; PHP Developers > Mailing List > Subject: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: > sprintf) > > > O

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

Consider the following, there are a lot more PHP users then PHP developers and considering that not all PHP developers are actively involved in the bug solving process (many are involved with PEAR/PECL/Documentation and so on) there are very few people actively working on resolving bugs. This ma

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

On Wednesday, January 15, 2003, at 08:48 AM, David Sklar wrote: The wording could be something like "NotValidBug" or something like that. I think the issue that Adam is bringing up is that "Bogus" has a derogatory connotation. Changing it doesn't necessarily make users who don't do necessary res

RE: [PHP-DEV] Re: #21659 [Com]: sprintf

> On January 15, 2003 10:27 am, Adam Wright wrote: > > Last ditch effort of "NotAPHPBug"? ;) > > This too may not be a correct solution all the time. Consider > 75th duplicate > report of an invalid or even a resolved bug report. It may have > been a bug at > some point, but certainly is not anymor

RE: [PHP-DEV] Re: #21659 [Com]: sprintf

> +1 on on that, but I do think that when a bug is set to bogus the reason > why it is bogus should always be noted. While on that topic, I had a bug recently set to bogus because it was reported against 4.2.3 while 4.3.0 was out. More than once in the bug reporting info there is a comment somethi

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

Agreed, on second thoughts those weren't terribly great example choices. I'm just coming from the point of view that you're generally better off not alienating someone for posting a bug before they've had their caffeine injection as they may in the future discover a legitimate bug which would be u

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

On January 15, 2003 10:27 am, Adam Wright wrote: > Last ditch effort of "NotAPHPBug"? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not anymore. It is bogu

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

Last ditch effort of "NotAPHPBug"? ;) adamw - Original Message - From: "Derick Rethans" <[EMAIL PROTECTED]> To: "Ilia A." <[EMAIL PROTECTED]> Cc: "Adam Wright" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 15, 2003 3:21 PM Subject: Re: [PHP-DEV] Re: #21659 [Com]: sprin

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

On Wed, 15 Jan 2003, Ilia A. wrote: > On January 15, 2003 10:14 am, Adam Wright wrote: > > Agreed in general. And whilst I'm here can I throw in my 2c about "Bogus"? > > Although an accurate description, it's hardly likely to be perceived as > > friendly. If you've taken the time to report a bug,

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

On January 15, 2003 10:14 am, Adam Wright wrote: > Agreed in general. And whilst I'm here can I throw in my 2c about "Bogus"? > Although an accurate description, it's hardly likely to be perceived as > friendly. If you've taken the time to report a bug, even if you are in > error, having it thrown

[PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)

On 15 Jan 2003 [EMAIL PROTECTED] wrote: > Why has this bug been marked as Bogus when it's a Duplicate? It seems > to be increasingly common for this to happen -- when did it become > standard policy to set duplicate report to Bogus? Two exactly the same bugs were posted one minute after eachothe

[PHP-DEV] Re: #21659 [Com]: sprintf

Agreed in general. And whilst I'm here can I throw in my 2c about "Bogus"? Although an accurate description, it's hardly likely to be perceived as friendly. If you've taken the time to report a bug, even if you are in error, having it thrown back as "Bogus" seems pretty mean. How about a less antag

RE: [PHP-DEV] Headers required?

On Wed, 15 Jan 2003, Vinod Panicker wrote: > Thanks for the quick reply... > > But is there something that I can do right now that will allow this code > to work with php 4.2.3? You could add the necessary code from here: http://news.php.net/article.php?group=php.cvs&article=16651 -

RE: [PHP-DEV] Headers required?

Thanks for the quick reply... But is there something that I can do right now that will allow this code to work with php 4.2.3? Tx, Vinod. --- Vinod Panicker <[EMAIL PROTECTED]> Sr. Software Designer Geodesic Information Systems Ltd. -Original Message-

Re: [PHP-DEV] Headers required?

> What are the headers required out here to compile this code > successfully? Libs to link with? There is a SAPI API call for that (in HEAD, but I intend to merge it into the 4.3 branch). SAPI_API int sapi_get_fd(int *fd TSRMLS_DC); - Sascha -- PHP Development Mailing List

[PHP-DEV] Headers required?

Hi, I have a custom extension in which I want to write this piece of code -> /* {{{ proto int apache_client_socket() Get the client socket */ PHP_FUNCTION(apache_client_socket) { RETURN_LONG(((request_rec *)SG(server_context))->connection->client->fd); } /* }}} */ This code is somethi

Re: [PHP-DEV] variables_order annoyance

On Tue, 14 Jan 2003, Rasmus Lerdorf wrote: > > Check out this bug report: > > > > http://bugs.php.net/16155 > > Ah thanks, that's where I remember the discussion from. I do disagree > with one part: > >(c) It shouldn't be possible to prevent $_GET, $_POST, >$_COOKIE, and $_FILES