Am Mo, den 09.05.2005 schrieb Jani Taskinen um 23:17:
> Just curious..why was it disabled..? :)
>
> --Jani
>
Afaik someone disabled it when PHP4 Windows didn't support zlib by
default.
/Georg
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/uns
Just curious..why was it disabled..? :)
--Jani
On Mon, 9 May 2005, Georg Richter wrote:
georg Mon May 9 13:45:51 2005 EDT
Modified files: (Branch: PHP_4_3)
/php-src NEWS
/php-src/ext/mysql/libmysql config-win.h
Log:
fix for bug #32116 (mysql compressed
On 2005/03/24, at 8:34, Ilia Alshanetsky wrote:
Moriyoshi Koizumi wrote:
moriyoshi Wed Mar 23 18:30:19 2005 EDT
Modified files: (Branch: PHP_4_3)
/php-src NEWS /php-src/ext/mbstring/libmbfl/mbfl mbfilter.c
Log:
- MFH: fix bug #32311 (mb_encode_mimeheader() does not prop
Moriyoshi Koizumi wrote:
moriyoshi Wed Mar 23 18:30:19 2005 EDT
Modified files: (Branch: PHP_4_3)
/php-src NEWS
/php-src/ext/mbstring/libmbfl/mbfl mbfilter.c
Log:
- MFH: fix bug #32311 (mb_encode_mimeheader() does not properly escape
characters).
As Ze
On 2005/01/22, at 4:50, Ilia Alshanetsky wrote:
Moriyoshi Koizumi wrote:
Right, but the browsers send filenames in its particular form, whose
path delimiter could be '\\'. Isn't this causing another problem on
a *NIX system where '\\' isn't regarded as a delimiter by
php_basename()?
No, browsers s
Moriyoshi Koizumi wrote:
> Right, but the browsers send filenames in its particular form, whose
> path delimiter could be '\\'. Isn't this causing another problem on
> a *NIX system where '\\' isn't regarded as a delimiter by php_basename()?
No, browsers send filenames however they like, we cannot
On 2005/01/22, at 1:12, Ilia Alshanetsky wrote:
Moriyoshi Koizumi wrote:
What is really confusing around this stuff, is that php_basename() is
all but designed to work on the filesystem where the script is
running,
while the filename coming from the outside isn't necessarily given in
the same sche
Moriyoshi Koizumi wrote:
> What is really confusing around this stuff, is that php_basename() is
> all but designed to work on the filesystem where the script is running,
> while the filename coming from the outside isn't necessarily given in
> the same scheme. For example, php_basename() is unlike
On 2005/01/22, at 0:02, Ilia Alshanetsky wrote:
Uhm yes. The purpose of the code is to trim characters from the
filename that could be interpreted as a path consequently leading to
all sorts of interesting vulnerabilities. Given that we have a
function for this very purpose called php_basenam
Uhm yes. The purpose of the code is to trim characters from the filename
that could be interpreted as a path consequently leading to all sorts of
interesting vulnerabilities. Given that we have a function for this very
purpose called php_basename() it would only seem logic to use it,
instead of
On 2005/01/21, at 2:57, Ilia Alshanetsky wrote:
iliaa Thu Jan 20 12:57:42 2005 EDT
Modified files: (Branch: PHP_4_3)
/php-src NEWS
/php-src/main rfc1867.c
/php-src/ext/standard string.c
Log:
MFH: Fixed bug #31398 (When magic_guotes_gpc are enabled filenames
On Tue, 18 Jan 2005, Ilia Alshanetsky wrote:
> iliaa Mon Jan 17 19:14:56 2005 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src NEWS
> /php-src/ext/standard file.c
> Log:
> Fixed bug #31580 (fgetcsv() problematic with "" escape sequences).
Add a testcase
On Tue, 7 Dec 2004 14:20:58 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> > setting session.cookie_lifetime to non-zero value leads to
> > session invalidation in that time, even if the session is
> > active and the user is still working with it.
>
> Your change affected the code
setting session.cookie_lifetime to non-zero value leads to
session invalidation in that time, even if the session is
active and the user is still working with it.
Your change affected the code path of standard session
cookies which don't have an explicit expiry date. There is
no point
On Tue, 7 Dec 2004 13:56:36 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Dec 2004, Antony Dovgal wrote:
>
> > On Tue, 7 Dec 2004 13:22:15 +0100 (CET)
> > Sascha Schumann <[EMAIL PROTECTED]> wrote:
> >
> >> Please revert. It is intentional that a cookie is only sent
> >
On Tue, 7 Dec 2004, Antony Dovgal wrote:
On Tue, 7 Dec 2004 13:22:15 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
Please revert. It is intentional that a cookie is only sent
when the client has not yet transferred the same session id
to us using a cookie.
5.0 & 5.1 behave
On Tue, 7 Dec 2004 13:22:15 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> Please revert. It is intentional that a cookie is only sent
> when the client has not yet transferred the same session id
> to us using a cookie.
5.0 & 5.1 behave wrong then, as they send cookie o
Please revert. It is intentional that a cookie is only sent
when the client has not yet transferred the same session id
to us using a cookie.
- Sascha
On Tue, 7 Dec 2004, Antony Dovgal wrote:
tony2001Tue Dec 7 03:21:39 2004 EDT
Modified files: (Branch
Hi,
On Wednesday 17 November 2004 18.13, Pierre-Alain Joye wrote:
> pajoye Wed Nov 17 12:13:42 2004 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src NEWS
> /php-src/ext/gd/libgd gd.c
> Log:
> - Fix #30739, imagefill does not set back the alphablending mode
What abo
Thanks.
At 01:50 PM 8/25/2004 -0700, Andrei Zmievski wrote:
On Tue, 24 Aug 2004, Andi Gutmans wrote:
> Can't you use zend_hash_apply() for this? I know it might be slightly
> slower but I don't think it'd be noticable. Copy&pasting the hash code
is a
> problem because if we change the hash code th
On Tue, 24 Aug 2004, Andi Gutmans wrote:
> Can't you use zend_hash_apply() for this? I know it might be slightly
> slower but I don't think it'd be noticable. Copy&pasting the hash code is a
> problem because if we change the hash code this part would probably not be
> maintained (at least not a
Can't you use zend_hash_apply() for this? I know it might be slightly
slower but I don't think it'd be noticable. Copy&pasting the hash code is a
problem because if we change the hash code this part would probably not be
maintained (at least not automatically).
Andi
At 08:57 PM 8/24/2004 +,
Ilia, add please a comma here, buildconf fails without it:
Index: config.m4
===
RCS file: /repository/php-src/ext/gd/config.m4,v
retrieving revision 1.120.2.21
diff -u -r1.120.2.21 config.m4
--- config.m4 27 Jul 2004 00:27:10 -
On 2004/07/20, at 10:03, Ilia Alshanetsky wrote:
return; \
switch (Z_TYPE_P(c)) { \
case IS_LONG: \
- RETURN_BOOL(iswhat(Z_LVAL_P(c))); \
+ if (Z_LVAL_P(c) < 255 && Z_LVAL_P(c) > -127)
This doesn't seem right.
Most likely: Z_LVAL_P(c) <= 2
I know but it should be in for the final release of 4.3.6.
At 11:25 PM 4/8/2004 +0200, Derick Rethans wrote:
On Thu, 8 Apr 2004, Andi Gutmans wrote:
> andi Thu Apr 8 17:23:31 2004 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src NEWS
> Log:
> - News
Tarballs
On Thu, 8 Apr 2004, Andi Gutmans wrote:
> andi Thu Apr 8 17:23:31 2004 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src NEWS
> Log:
> - News
Tarballs were already rolled, so this message is not in there...
Derick
--
PHP CVS Mailing List (http://www.php.net
Can you please hold 4.3.6. I think we might have found a bug!
At 12:42 PM 4/8/2004 +, Ilia Alshanetsky wrote:
iliaa Thu Apr 8 08:42:31 2004 EDT
Modified files: (Branch: PHP_4_3)
/php-srcNEWS
Log:
Prepare news file for release.
http://cvs.php.net/diff.php/
On Tue, 6 Apr 2004, Andi Gutmans wrote:
> I think you forgot to nuke the 4.3.6RC2 line :)
Nope, I didn't. It was a deliberate choice as we usually always do this
only when releasing the final release. (There is also still a 4.3.6RC1
line)
Derick
>
> At 06:12 PM 4/6/2004 +, Derick Rethans w
I think you forgot to nuke the 4.3.6RC2 line :)
At 06:12 PM 4/6/2004 +, Derick Rethans wrote:
derick Tue Apr 6 14:12:05 2004 EDT
Modified files: (Branch: PHP_4_3)
/php-srcNEWS
Log:
- Update NEWS with fugbix.
http://cvs.php.net/diff.php/php-src/NEWS?r1=1.12
Wouldn't it be just fine to leave those RC sections at place?
Those are releases too, sort of. :)
--Jani
On Tue, 23 Mar 2004, Ilia Alshanetsky wrote:
>iliaa Tue Mar 23 14:53:13 2004 EDT
>
> Modified files: (Branch: PHP_4_3)
>/php-src NEWS
> Lo
On Sun, 2004-03-07 at 09:12, Ilia Alshanetsky wrote:
> On March 06, 2004 05:48 pm, you wrote:
> > Is there any chance we can fix it without making the setting
> > system ini option and leaving the functionality as it was?
>
> Suggestsions on how to do that are more then welcome. However the behav
On March 06, 2004 05:48 pm, you wrote:
> Is there any chance we can fix it without making the setting
> system ini option and leaving the functionality as it was?
Suggestsions on how to do that are more then welcome. However the behaviour of
the code is such that it affects the entire PHP thus cr
On Sun, 2004-03-07 at 04:30, Ilia Alshanetsky wrote:
> MFH: Fixed bug #27421 (mbstring.func_overload should be system ini setting)
Is there any chance we can fix it without making the setting
system ini option and leaving the functionality as it was?
Moriyoshi
--
PHP CVS Mailing List (http://
On Sun, Jan 25, 2004 at 11:55:44PM -, Ilia Alshanetsky wrote:
> iliaa Sun Jan 25 18:55:44 2004 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src NEWS
> Log:
> bug fixing news.
...
> +- Fixed bug #26814 (On parse error include included file, terminate
>
Ah well, who would have TZ prefixed env vars anyway? :)
btw. you should put the #ifdef HAVE_TZSET around that addition
in php_putenv_destructor()..
--Jani
On Wed, 15 Oct 2003, Wez Furlong wrote:
>wezTue Oct 14 20:14:38 2003 EDT
>
> Modified files:
Oops, I missed that point. Thanks.
Moriyoshi
Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> The fix DID NOT go into 4.3.4RC1, please move the news entry to RC2
> placeholder.
>
> Thanks.
>
> Ilia
>
> P.S. To avoid confusion please try to not make commits once the changes to the
> versions fi
The fix DID NOT go into 4.3.4RC1, please move the news entry to RC2
placeholder.
Thanks.
Ilia
P.S. To avoid confusion please try to not make commits once the changes to the
versions files have been made until the versions are restored to dev tree.
On September 29, 2003 10:04 pm, Jani Taskinen
I'm not sure but I think this fix did NOT go into 4.3.4RC1?
(in which case, this NEWS entry belongs in the 4.3.4RC2 section)
--Jani
On Tue, 30 Sep 2003, Moriyoshi Koizumi wrote:
>moriyoshi Mon Sep 29 20:41:57 2003 EDT
>
> Modified files: (Branch: PHP_4
FYI, we don't usually add new features in bugfix releases,
such as PHP 4.3.3 is supposed to be..
--Jani
On Thu, 24 Jul 2003, Uwe Schindler wrote:
>thetaphi Thu Jul 24 13:42:40 2003 EDT
>
> Modified files: (Branch: PHP_4_3)
>/php-src NEWS
>
On July 24, 2003 03:16 pm, Uwe Schindler wrote:
> revert the shitty whitespace patch...
Why, do we really need the extra whitespace?
Ilia
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, 29 Jun 2003, Sascha Schumann wrote:
>On Sun, 29 Jun 2003, Jani Taskinen wrote:
>
>> sniper Sat Jun 28 22:08:17 2003 EDT
>>
>> Modified files: (Branch: PHP_4_3)
>> /php-src NEWS
>> Log:
>> Note about PCRE upgrade
>
>Hrm, where is the diff?
I thi
On Sun, 29 Jun 2003, Jani Taskinen wrote:
> sniperSat Jun 28 22:08:17 2003 EDT
>
> Modified files: (Branch: PHP_4_3)
> /php-src NEWS
> Log:
> Note about PCRE upgrade
Hrm, where is the diff?
- Sascha
--
PHP CVS Mailing List (http://www.php.net/)
T
42 matches
Mail list logo
