Perhaps this is a stupid question, but has anyone ensured that zlib
rev 1.2.3 still exhibits this behavior? The trouble ticket is close
to useless for recapping this; but I'm happy to shepard a fix or some
solution through the zlib dev team.
The ticket indiciated that PHP is using it's own fork
My bad, I remembered the initial post wrong. Still, the primary bug report
should be for the zlib fellas. They're the ones who need to fix their lib.
Secondary, maybe php folks can see if the problem can be worked around. But
still, the guys with the real problem are the zlib guys. Have you filed a
Guys,
It's really not about who is RM. The main reason why PHP 5.1 has been
delayed so much is because every time we were about to release,
another critical problem creeped up. We had PDO problems, class
constants, reference issues, date issues, security issues, and others
(more or less in th
--- and as was mentioned on IRC earlier, anyone who gives a damn about the
future of PHP isn't going to be someone who talks about forking it and
making rogue releases. You _are_ trolling when you do this, and you're not
doing the reputation of the dev team any good. I know you're one of the
good
To correct the quite bad Dutch translations of the documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 4 Oct 2005, Christian Schneider wrote:
Two things to consider:
1) If the PHP maintainers are getting sick of BC then it might be better
to break BC than to lose maintainers.
Well, losing couple of trolls like me is not bad thing, is it? :)
But yes, if PHP can't evolve, this wil
Lukas Smith wrote:
to keep customers. This half-assed attempt at maintain BC is what is
really causing major problems.
The problem would be that this new PHP would be a wild mix of all
different changes. While I wouldn't mind a shiny new PHP with
&-references removed altogether which always cop
Ron,
But the error I'm seeing is *not* a segfault... Bad input data causes
unbounded memory allocations which are eventually terminated when the
per script memory limit is hit. At this point, PHP traps the condition
and terminates the script 'gracefully'. The problem is that a 'graceful'
term
Hello Christian,
Tuesday, October 4, 2005, 10:14:05 AM, you wrote:
> Marcus Boerger wrote:
>> E_STRICT in 5.0, 51 is the least thing we need to do and probably we should
>> simply stop supporting 4.4 otherwise we never have our user base upgrade.
> While we would love to upgrade to PHP5 there is
Hello Dmitry,
Tuesday, October 4, 2005, 11:16:36 AM, you wrote:
> Marcus, Derick,
> $var = & $this is proper code, however changing $var after such assignment
> right in this methid can cause mesh. Only this method will be affected. Look
> into example:
Which straw are you now reaching for? The
Tim,
I'm no core PHP developer (just a user) but I'm pretty convinced that
there's nothing that can be done to solve this from PHP. PHP just passes
bytes to the zlib functions (which are implemented by the zlib guys). If one
of these functions causes a segfault, there's really nothing you can do.
This is starting to sound like the dispute in the initial bug
report. Regardless of the root cause, this is a serious bug in PHP
which exposes any script using gzinflate to denial of service attacks.
While I'm sure extending zlib provides the most elegant fix to this
problem, it should be p
I'm writing a PHP extension in C++ which need to provide a function which
will take as a parameter a zval *. This zval * should, when the function
has completed its task, simply be returned unmodified. How do I accomplish
this? I've tried something like this:
return_value = v;
There are two
On Oct 4, 2005, at 11:50 AM, Tim Nufire wrote:
Ramus,
Thanks for the response. Unfortunately, I don't have any great
ideas on how to patch this and for now have just stopped using
gzinflate :-/ Is there a way to reopen bug 30153? That description
of this issue is pretty good and, even if
Ramus,
Thanks for the response. Unfortunately, I don't have any great ideas on
how to patch this and for now have just stopped using gzinflate :-/ Is
there a way to reopen bug 30153? That description of this issue is
pretty good and, even if the bug is hard to fix, it should still be
tracked
Matthew Kavanagh wrote:
> Would that really be a problem, given that compressing a compressed file
> and compressing an uncompressed file will usually yield similar sized
> resultant files?
>
...and I failed to see the previous email that says the same thing.
Genius at work. ;)
--
PHP Internals
Derick Rethans wrote:
> On Mon, 3 Oct 2005, Greg Beaver wrote:
>
>
>>> 1. zlib is required now with php, and by default php isn't installed
>>> with zlib nor does configure catch this, so, while make install is
>>> running and when pear is being installed make dies leaving a bad
>>> installat
Marcus Boerger schrieb:
> No. And it is even worse. We start maintaining BC for things we always
> agreed we do not support
This gave me a very silly idea (or not?):
Release a PHP 4.9 version or something like that!
And here's what it looks like: It is a complete PHP 5.1 in disguise plus
a para
Oliver Grätz wrote:
Ford, Mike schrieb:
Yes, very true. I've mentioned before that I think PHP 5's object
thingummies should be referred to as "handles" (and I'm sure I
actually saw this usage in early versions of the PHP 5 or Zend
Engine 2 proposals). Then, it's much clearer that:
$obj2 = $
Ford, Mike schrieb:
> Yes, very true. I've mentioned before that I think PHP 5's object
> thingummies should be referred to as "handles" (and I'm sure I actually saw
> this usage in early versions of the PHP 5 or Zend Engine 2 proposals). Then,
> it's much clearer that:
>
>$obj2 = $obj1
>
Bart van Bragt wrote:
The 'communicate more clearly' part is what this (IMO) all boils down
to. As I said, I understand that BC breaks are sometimes needed, no
problem with that. The problem lies in the fact that we now all of the
I made a suggestion in regards to this a few days ago on this
On Tue, 2005-10-04 at 09:49 +0200, Derick Rethans wrote:
> I am quite getting tired of having to maintain BC for *every* little
> stupid thing we ever did. I think it's time to start with a clean slate
> as it's all getting way to annoying to maintain (and know what subtle
> differences there ar
Lukas Smith wrote:
See my note above. Everybody knows that clean ups will cause BC breaks
and everybody knows that designing code that never breaks BC is a futile
attempt that simply takes to long to be of any use out in the real
world. We just have to communicate more clearly when we do break
Bart van Bragt wrote:
Derick Rethans wrote:
But who says your code should run on the new version? You don't *have*
to upgrade per se. It merely allows newly developed projects to run on
a cleaner version of PHP, which would undoubtfully also be faster
(because we wouldn't have any BC ballast)
Petar Nedyalkov wrote:
proper scopes for global, classes and functions.
will allow for local variables for functions and classes without having to
use $this->foo in classes and will allow for a more c/c++ like classes.
I think this will pollute the namespace a lot and may lead to spaghetti cod
On 03 October 2005 15:41, Robert Cummings wrote:
> Amazing how fast the assumption has become that passing
> object values in
> PHP5 is identical to passing the object by reference. It is not the
> same, there are subtle differences. Either way I'm not weighing in on
> the $ref = &$this issue, onl
Hello
I'm writing a PHP extension in C++ which need to provide a function
which will take as a parameter a zval *. This zval * should, when the
function has completed its task, simply be returned unmodified. How do I
accomplish this? I've tried something like this:
PHP_FUNCTION(my_func) {
Derick Rethans wrote:
But who says your code should run on the new version? You don't *have*
to upgrade per se. It merely allows newly developed projects to run on a
cleaner version of PHP, which would undoubtfully also be faster (because
we wouldn't have any BC ballast).
If I have a newly deve
On Tue, 4 Oct 2005, Bart van Bragt wrote:
> Lukas Smith wrote:
> > I think that eZ is an example of a company that shows its willing to take a
> > risk in betting their money on PHP6 only, because they are producing a
> > product that will then simply be on a cleaner basis for its customers. Other
On Tue, 4 Oct 2005, Bart van Bragt wrote:
> Starting with a clean slate would cool for you (it would enable you to do new
> and cool things) but it would either force us to switch to a more stable
> language or keep two completely different codebases. I know what I would
> choose.
But who says yo
On Tue, 4 Oct 2005, Gareth Ardron wrote:
> Of course, the key thing here would be making sure that you could run
> php4.x/5.x alongside a php6 install so that people can easily test things
> without risk of breaking existing apps still on the same server.
It's quite easy to set something like tha
Lukas Smith wrote:
I think that eZ is an example of a company that shows its willing to
take a risk in betting their money on PHP6 only, because they are
producing a product that will then simply be on a cleaner basis for its
customers. Other companies in much more controlled environments would
Lukas Smith wrote:
I think that eZ is an example of a company that shows its willing to
take a risk in betting their money on PHP6 only, because they are
producing a product that will then simply be on a cleaner basis for
its customers. Other companies in much more controlled environments
wou
Derick Rethans wrote:
> On Tue, 4 Oct 2005, Christian Schneider wrote:
>
>
>>Jani Taskinen wrote:
>>
>>>Yes, but OO in PHP 4 is illusion.
>>
>>Ok, I see, I replied to a troll. Silly of me. Won't happen again after this
>>one, I promise.
>
>
> Atleast he contributes something useful to the P
Bart van Bragt wrote:
There are some whacky things in PHP4 and PHP5 that need to be fixed and
to fix that BC sometimes breaks. No problem with that. The problem is
that you're breaking BC again while almost no-one has switched to PHP5
yet because of the BC breaks between 4.x and 5.0. Breaking
Derick Rethans wrote:
I am quite getting tired of having to maintain BC for *every* little
stupid thing we ever did. I think it's time to start with a clean slate
as it's all getting way to annoying to maintain (and know what subtle
differences there are between PHP versions).
How do you think
Marcus, Derick,
$var = & $this is proper code, however changing $var after such assignment
right in this methid can cause mesh. Only this method will be affected. Look
into example:
x = 2;
}
}
$x = new foo();
var_dump($x);
?>
The code above doesn't destroy object and doesn't change EG(This).
On Tue, 4 Oct 2005, Christian Schneider wrote:
> Jani Taskinen wrote:
> > Yes, but OO in PHP 4 is illusion.
>
> Ok, I see, I replied to a troll. Silly of me. Won't happen again after this
> one, I promise.
Atleast he contributes something useful to the PHP project too.
regards,
Derick
--
On Tue, 4 Oct 2005, Stefan Walk wrote:
> On 10/4/05, Derick Rethans <[EMAIL PROTECTED]> wrote:
> > On Mon, 3 Oct 2005, Greg Beaver wrote:
> >
> > > > 1. zlib is required now with php, and by default php isn't installed
> > > > with zlib nor does configure catch this, so, while make install is
Derick Rethans wrote:
We are not ignoring it. However the single most useful feature from PEAR POV
was dropped from PHP5: namespaces.
That's lame, this has nothing to do with E_STRICT warnings or other
dubious code.
How is it dubious to support PHP4 and PHP5 with the same code base?
There
On Tue, 4 Oct 2005, Lukas Smith wrote:
> Marcus Boerger wrote:
>
> > You should face reality that php 5 is a bit different than php 4.
> > Many of the things changed in php 5 were made to support exactly pear
> > development but pear is absolutley ignoring it. Why can't at least the
> > things th
On 10/4/05, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 3 Oct 2005, Greg Beaver wrote:
>
> > > 1. zlib is required now with php, and by default php isn't installed
> > > with zlib nor does configure catch this, so, while make install is
> > > running and when pear is being installed m
Marcus Boerger wrote:
You should face reality that php 5 is a bit different than php 4.
Many of the things changed in php 5 were made to support exactly pear
development but pear is absolutley ignoring it. Why can't at least the
things that shall be shipped in 5.1 fashion - especially since you'
Jani Taskinen wrote:
Yes, but OO in PHP 4 is illusion.
Ok, I see, I replied to a troll. Silly of me. Won't happen again after
this one, I promise.
Nobody's bashing you for using PHP. Just for using PHP 4. :)
Are you reading my posts? Oh no, I forgot, you're just trolling.
Over an
On Tue, 4 Oct 2005, Christian Schneider wrote:
Jani Taskinen wrote:
On Tue, 4 Oct 2005, Christian Schneider wrote:
And the code _does_ work with PHP5.
il·lu·sion:
1. An erroneous perception of reality.
2. An erroneous concept or belief.
3. The condition of being deceived by
Hi Marcus Boerger, you wrote:
> Hello Derick,
>
>
>>Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
>>anyway.
>
>
> I can only emphasize this.
Frankly, this is not the PHP users fault at all.
If PHP5 would have been the PHP5 many had expected and
had broken lots of more t
Jani Taskinen wrote:
On Tue, 4 Oct 2005, Christian Schneider wrote:
And the code _does_ work with PHP5.
il·lu·sion:
1. An erroneous perception of reality.
2. An erroneous concept or belief.
3. The condition of being deceived by a false perception or belief.
4. Something, su
Marcus Boerger wrote:
E_STRICT in 5.0, 51 is the least thing we need to do and probably we should
simply stop supporting 4.4 otherwise we never have our user base upgrade.
While we would love to upgrade to PHP5 there is one killer for us so far:
None of the open caches (Zend cache is not an opt
Hello all,
Tuesday, October 4, 2005, 9:59:20 AM, you wrote:
> dmitry Tue Oct 4 03:59:20 2005 EDT
> Modified files:
> /php-src/ext/standard/tests/strings bug21453.phpt
> Log:
> Unicode support
>
>
> http://cvs.php.net/diff.php/php-src/ext/standard/te
On Tue, 4 Oct 2005, Christian Schneider wrote:
Derick Rethans wrote:
Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion anyway.
No, it's not. What are you talking about? We've been happily using PHP4 with
OOP for years. That's basic OO like encapsulating data and inheritanc
Hello Derick,
Tuesday, October 4, 2005, 9:49:00 AM, you wrote:
> On Mon, 3 Oct 2005, Dmitry Stogov wrote:
>> At second disallowing such assignments and passign $this by reference will
>> breake a lot of PHP4 code (Mamaba CMS).
>> In PHP4 passing $object by refernce and by value had completely di
Derick Rethans wrote:
Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
anyway.
No, it's not. What are you talking about? We've been happily using PHP4
with OOP for years. That's basic OO like encapsulating data and
inheritance to extend behaviour. Nothing of that "fancy" ex
Hello Derick,
Tuesday, October 4, 2005, 9:41:39 AM, you wrote:
> On Mon, 3 Oct 2005, Christian Schneider wrote:
>> a) I know that you now are going to bash me for mentioning PHP4
>> b) No, I don't think this is very common or elegant
>>
>> But disallowing it might break existing code, no?
> Ye
On Mon, 3 Oct 2005, Dmitry Stogov wrote:
> At second disallowing such assignments and passign $this by reference will
> breake a lot of PHP4 code (Mamaba CMS).
> In PHP4 passing $object by refernce and by value had completely different
> semantic.
Yes I know. In PHP 4 the OO was totally crap, and
On Mon, 3 Oct 2005, Christian Schneider wrote:
> a) I know that you now are going to bash me for mentioning PHP4
> b) No, I don't think this is very common or elegant
>
> But disallowing it might break existing code, no?
Yes, but thinking that PHP 4 "OO" code runs on PHP 5 is an illusion
anyway
On Mon, 3 Oct 2005, Greg Beaver wrote:
> > 1. zlib is required now with php, and by default php isn't installed
> > with zlib nor does configure catch this, so, while make install is
> > running and when pear is being installed make dies leaving a bad
> > installation.
>
> I could elimina
56 matches
Mail list logo
