Hello,
I am writing custom rfc1867 code on a http server so in php application code I
can just
use the file directly instead of being processed by rfc1867.c.
I went through the rfc1867 code but the code is hard to understand. When data
comes as
chunks from the browser, whats a good logic to det
Hello.
Sorry for the delay...
> Committed!
Thank yoy. :-)
> > out of curiosity: Which compiler/platform complained about that? Many
> > compilers accept the trailing comma as a language extension, while C89,
> > the standard we currently follow, forbids it (C99 would allow it).
> >
> > Could
On Wed, Jun 17, 2009 at 1:16 AM, jvlad wrote:
>>
>>> Under windows php crashes in fastcgi...
>>
>> Pardon? where?
>
> Pardon, threre:
> http://bugs.php.net/bug.php?id=48563
I missed it, however I can't reproduce here. Can you try using a
snapshot please?
If it still crashed, can you add more inf
On Wed, Jun 17, 2009 at 1:16 AM, jvlad wrote:
>>
>>> Under windows php crashes in fastcgi...
>>
>> Pardon? where?
>
> Pardon, threre:
> http://bugs.php.net/bug.php?id=48563
Thanks for the notice!
I missed it, however I can't reproduce here. Can you try using RC4 or
a snapshot please?
If it still
> Plan to share any of these errors with us? We don't have all platforms
> available for testing.
>
> Scott
/bin/sh
/home/jvlad/php/php-5.3.0RC3/libtool --silent --preserve-dup-deps
--mode=compile
gcc -I/home/jvlad/php/php-5.3.0RC3/ext/fileinfo/libmagic -Iext/fileinfo/
-I/home/jvlad/php/php-
>> Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/
>> amd64,
>> NetBSD 3.1/x86, and OpenBSD 4.1/x86?
>> Under these platforms gcc hangs in
>> php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo
>> produces
>> further errors in spl and date.
>> Under Solaris 2
>
>> Under windows php crashes in fastcgi...
>
> Pardon? where?
Pardon, threre:
http://bugs.php.net/bug.php?id=48563
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 17 Jun 2009, at 00:03, jvlad wrote:
Hi All,
Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/
amd64,
NetBSD 3.1/x86, and OpenBSD 4.1/x86?
Under these platforms gcc hangs in
php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo
produces
further errors in
On Wed, Jun 17, 2009 at 1:03 AM, jvlad wrote:
> Under windows php crashes in fastcgi...
Pardon? where?
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi All,
Did anybody experiece troubles compiling php 5.3RC under FreeBSD 6.2/amd64,
NetBSD 3.1/x86, and OpenBSD 4.1/x86?
Under these platforms gcc hangs in
php-5.3.0RC3/ext/fileinfo/libmagic/apprentice.c. Disabling fileinfo produces
further errors in spl and date.
Under Solaris 2.8/Sparc/Sparc6
Hi,
This seems like a trivial change from the implementation side, so I am
not worried about changing this for the "better" even after RC4 (given
proper documentation.
So here are the choices I see:
1) stay as is .. aka defaults to on while not emiting an E_DEPRECATED,
do emit E_DEPRECAT
On Wed, Jun 17, 2009 at 12:01 AM, Lukas Kahwe Smith wrote:
> It seems only you and Derick have expressed an opinion.
> If no one else speaks up I would tend to leave as is and fix it in 5.3.1
> (and HEAD asap) and simply make sure that we put it in bold letters in the
> UPGRADING guide that you re
On 16.06.2009, at 20:53, Stanislav Malyshev wrote:
Hi!
so if this issue is also in 5.2 .. i feel even less inclined to
delay a stable 5.3 release because of this issue. have we made it
worse in our attempts to fix it? the fact that this bug isnt fixed
yet could mean
No, it was crash be
On Tue, Jun 16, 2009 at 9:10 PM, Greg Beaver wrote:
> Hannes Magnusson wrote:
>> On Tue, Jun 16, 2009 at 20:59, Greg Beaver wrote:
>>
>>> Lukas Kahwe Smith wrote:
>>>
1) its not about "punishing", its about alerting people that they are
relying on stuff that will go away
2) E_DEPRECA
Hannes Magnusson wrote:
> On Tue, Jun 16, 2009 at 20:59, Greg Beaver wrote:
>
>> Lukas Kahwe Smith wrote:
>>
>>> 1) its not about "punishing", its about alerting people that they are
>>> relying on stuff that will go away
>>> 2) E_DEPRECATE is for development only and only as a check you en
On Jun 16, 2009, at 11:59 AM, Stefan Walk wrote:
On 16 Jun 2009, at 20:49, Lukas Kahwe Smith wrote:
1) its not about "punishing", its about alerting people that they
are relying on stuff that will go away
2) E_DEPRECATE is for development only and only as a check you
enable now and then
On Tue, Jun 16, 2009 at 20:59, Greg Beaver wrote:
> Lukas Kahwe Smith wrote:
>> 1) its not about "punishing", its about alerting people that they are
>> relying on stuff that will go away
>> 2) E_DEPRECATE is for development only and only as a check you enable
>> now and then
>> 3) its off in both
On 16.06.2009, at 20:59, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
1) its not about "punishing", its about alerting people that they are
relying on stuff that will go away
2) E_DEPRECATE is for development only and only as a check you enable
now and then
3) its off in both of the php.ini's w
On 16.06.2009, at 20:53, Stanislav Malyshev wrote:
We don't need to delay it if we decide to commit my (incomplete) fix
now. Anyway, it's your decision, one of the three: 1. leave it as
is, 2. commit incomplete fix now, 3. wait for complete fix. I agree
3 is the worst, I'd go with 2 but if
On 16 Jun 2009, at 20:49, Lukas Kahwe Smith wrote:
1) its not about "punishing", its about alerting people that they
are relying on stuff that will go away
2) E_DEPRECATE is for development only and only as a check you
enable now and then
3) its off in both of the php.ini's we will ship wi
Lukas Kahwe Smith wrote:
> 1) its not about "punishing", its about alerting people that they are
> relying on stuff that will go away
> 2) E_DEPRECATE is for development only and only as a check you enable
> now and then
> 3) its off in both of the php.ini's we will ship with 5.3
OK, then the UPGR
hi Lukas,
On Tue, Jun 16, 2009 at 8:49 PM, Lukas Kahwe Smith wrote:
>
> On 16.06.2009, at 19:39, Greg Beaver wrote:
>
>> Daniel Convissor wrote:
>>>
>>> Folks:
>>>
I propose the following behavior: "Throw a deprecated warning unless
magic quotes are currently enabled and the
paramet
Hi!
so if this issue is also in 5.2 .. i feel even less inclined to delay a
stable 5.3 release because of this issue. have we made it worse in our
attempts to fix it? the fact that this bug isnt fixed yet could mean
No, it was crash before, now it doesn't crash for me but produces 400K
of e
On 16.06.2009, at 19:39, Greg Beaver wrote:
Daniel Convissor wrote:
Folks:
I propose the following behavior: "Throw a deprecated warning unless
magic quotes are currently enabled and the
parameter is to disable them".
The function is going away. A deprecated warning is necessary to
aler
On 16.06.2009, at 18:56, Stanislav Malyshev wrote:
Hi!
So lets delay fixing this issue until 5.3.1? Of course it can be
fixed in HEAD right now :)
Delaying the fix would mean we release 5.3.0 that in mostly default
config has an infinite loop bug. Maybe we can at least have temp fix
an
At 17:00 16/06/2009, Daniel Convissor wrote:
Folks:
> I propose the following behavior: "Throw a deprecated warning unless
> magic quotes are currently enabled and the
> parameter is to disable them".
The function is going away. A deprecated warning is necessary to alert
people of this fact, n
Daniel Convissor wrote:
> Folks:
>
>> I propose the following behavior: "Throw a deprecated warning unless
>> magic quotes are currently enabled and the
>> parameter is to disable them".
>
> The function is going away. A deprecated warning is necessary to alert
> people of this fact, no matter
Hi!
So whats going on here?
I noticed that the bug report hasn't been reopened .. but I think there
was also not commit yet .. ?
Well, it's not exactly the same bug - crash is not there anymore, but
infinite loop is. There's bug http://bugs.php.net/bug.php?id=48534 about
it so I decided not
Hi!
5.2 is likely to be released on Thursday, please, try to figure out a
solution before that or to convince Ilia to wait, thanks :)
Well, there is a patch I sent, which fixes the immediate problem, if
Ilia OKs it I can commit it any time. The comprehensive fix would take
some time though.
hi,
On Tue, Jun 16, 2009 at 6:56 PM, Stanislav Malyshev wrote:
> Hi!
>
>> So lets delay fixing this issue until 5.3.1? Of course it can be fixed in
>> HEAD right now :)
>
> Delaying the fix would mean we release 5.3.0 that in mostly default config
> has an infinite loop bug. Maybe we can at least
Hi!
So lets delay fixing this issue until 5.3.1? Of course it can be fixed
in HEAD right now :)
Delaying the fix would mean we release 5.3.0 that in mostly default
config has an infinite loop bug. Maybe we can at least have temp fix and
then when we have a proper one then remove it (or leave
Em Ter, 2009-06-16 às 15:25 +0200, Johannes Schlüter escreveu:
> Hi,
>
> out of curiosity: Which compiler/platform complained about that? Many
> compilers accept the trailing comma as a language extension, while C89,
> the standard we currently follow, forbids it (C99 would allow it).
>
> Could s
On Tue, Jun 16, 2009 at 16:00, Daniel
Convissor wrote:
> Folks:
>
>> I propose the following behavior: "Throw a deprecated warning unless
>> magic quotes are currently enabled and the
>> parameter is to disable them".
>
> The function is going away. A deprecated warning is necessary to alert
> peo
Folks:
> I propose the following behavior: "Throw a deprecated warning unless
> magic quotes are currently enabled and the
> parameter is to disable them".
The function is going away. A deprecated warning is necessary to alert
people of this fact, no matter how the function is used.
Thanks,
-
Hi,
out of curiosity: Which compiler/platform complained about that? Many
compilers accept the trailing comma as a language extension, while C89,
the standard we currently follow, forbids it (C99 would allow it).
Could somebody apply the patch - Thanks!
johannes
On Tue, 2009-06-16 at 19:54 +090
Pierre Joye wrote:
> On Tue, Jun 16, 2009 at 12:33 PM, Hannes
> Magnusson wrote:
>
>>> Because in PHP 6 (or next) the function "set_magic_quotes_runtime()" will be
>>> removed, so calling it without checking ini_get() will trigger a fatal
>>> error, no ?
>>>
>> And there is the problem.
>
Hollo.
Small build problem was found, in PHP5.3.0RC3.
Please apply this patch.
Best Regards,
--
Seiji Masugata
-- ../php-5.3.0RC3,orig/Zend/zend_stream.h 2009-03-12 07:11:53.0
+0900
+++ Zend/zend_stream.h 2009-06-16 15:04:33.0 +0900
@@ -38,7 +38,7 @@
ZEND_HANDL
On Tue, Jun 16, 2009 at 12:33 PM, Hannes
Magnusson wrote:
>> Because in PHP 6 (or next) the function "set_magic_quotes_runtime()" will be
>> removed, so calling it without checking ini_get() will trigger a fatal
>> error, no ?
>
> And there is the problem.
> The recommended way is:
> if(get_magic_
On Tue, Jun 16, 2009 at 12:24, Olivier B. wrote:
> Hannes Magnusson a écrit :
>>
>> On Tue, Jun 16, 2009 at 10:09, Pierre Joye wrote:
>>
>>>
>>> hi,
>>>
>>> On Tue, Jun 16, 2009 at 9:46 AM, Lukas Kahwe Smith
>>> wrote:
>>>
On 16.06.2009, at 05:08, Greg Beaver wrote:
>
>
Hannes Magnusson a écrit :
On Tue, Jun 16, 2009 at 10:09, Pierre Joye wrote:
hi,
On Tue, Jun 16, 2009 at 9:46 AM, Lukas Kahwe Smith wrote:
On 16.06.2009, at 05:08, Greg Beaver wrote:
Hi,
in PHP_5_3 if you're using set_magic_quotes_runtime(0), it raises an
E_DEPRECATED. I tho
On Tue, Jun 16, 2009 at 10:09, Pierre Joye wrote:
> hi,
>
> On Tue, Jun 16, 2009 at 9:46 AM, Lukas Kahwe Smith wrote:
>>
>> On 16.06.2009, at 05:08, Greg Beaver wrote:
>>
>>> Hi,
>>>
>>> in PHP_5_3 if you're using set_magic_quotes_runtime(0), it raises an
>>> E_DEPRECATED. I thought all that argum
On 16.06.2009, at 10:07, Derick Rethans wrote:
On Thu, 11 Jun 2009, Stanislav Malyshev wrote:
Bug #48247 appears to be not entirely fixed still, it still
produces a torrent
of warnings in certain configs (namely, take php.ini-production and
edit it to
enable error_log, don't touch anything
hi,
On Tue, Jun 16, 2009 at 9:46 AM, Lukas Kahwe Smith wrote:
>
> On 16.06.2009, at 05:08, Greg Beaver wrote:
>
>> Hi,
>>
>> in PHP_5_3 if you're using set_magic_quotes_runtime(0), it raises an
>> E_DEPRECATED. I thought all that argument was resolved to only throw
>> E_DEPRECATED for set_magic_q
On Thu, 11 Jun 2009, Stanislav Malyshev wrote:
> Bug #48247 appears to be not entirely fixed still, it still produces a torrent
> of warnings in certain configs (namely, take php.ini-production and edit it to
> enable error_log, don't touch anything else - I get 400K worth of warnings).
> Attached
On 11.06.2009, at 20:00, Stanislav Malyshev wrote:
Hi!
Bug #48247 appears to be not entirely fixed still, it still produces
a torrent of warnings in certain configs (namely, take php.ini-
production and edit it to enable error_log, don't touch anything
else - I get 400K worth of warnings)
On 10.06.2009, at 16:43, Johannes Schlüter wrote:
June 10th (today):
We package RC3, until then only critical
build fixes and similar which have to go in the RC, after review
(highlight me on IRC, mail etc.)
June 11th:
RC3 will be released
June 11th-17th
A small window for critical fixes
On 16.06.2009, at 05:08, Greg Beaver wrote:
Hi,
in PHP_5_3 if you're using set_magic_quotes_runtime(0), it raises an
E_DEPRECATED. I thought all that argument was resolved to only throw
E_DEPRECATED for set_magic_quotes_runtime(1)?
This is a major pain if magic_quotes are enabled and you nee
47 matches
Mail list logo
