On 26 Mar 2003 19:17:39 +0100
Martin Jansen <[EMAIL PROTECTED]> wrote:
> The plan is to move a lot of extension to PECL, once the
> infrastructure is rock-solid. Please don't ask, when this will happen
> and which extensions will be moved :-).
Yep, I know about this plan.
Ok, I just stated my IMHO
> I thought Siberia is much further, then PECL =)
> By the way, in Russian "PECL" sounds almost like a word, that
> means "hell"..
In German, it sounds like "pimple". I've always been saying
that it was a bad choice.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
On 26 Mar 2003 13:10:25 -0500
Sterling Hughes <[EMAIL PROTECTED]> wrote:
> Its a segfault, it will be fixed. Sockets is a standard, and atm very
> widely used and important extension - its not going to
> siberia^H^H^H^Hpecl.
I thought Siberia is much further, then PECL =)
By the way, in Russian "
Stanislav Malyshev wrote:
> Also refine namespaced includes
This seems not to work the way I expected:
TestCase.php
1
FooTest.php
1
CLI.php
1
E:\>php cli.php
Fatal error: Class 'footest' not found in E:\cli.php on line 6
--
Sebastian Bergmann
http://s
Maintenance of the PEAR package DB_NestedSet - which was allready accepted by the
community.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 26 Mar 2003 17:08:25 -, you wrote:
>Choosing between "case 0:" and (say) "case_identical 0:" would only be the
>same as choosing between == and === in an if statement -- it would just give
>the opportunity to do it using the elegant switch structure instead of the
>clumsy if...elseif..
At 21:22 26.03.2003, Andi Gutmans wrote:
At 08:43 PM 3/26/2003 +0100, Marcus Börger wrote:
Lets disallow both nesting function and NOT WORKING nested namespaces
(and classes?) for PHP5.
We changed a lot and took care about BC issues even more but why not get
rid of these shit? AND
why introducin
A discussion on irc (german) just reminded me of one of
my ideas for php 5:
Currently we have PHP_FE and PHP_FALIAS what about
making another one PHP_OLD_FE which handles those
names which are old that are incompatible with the naming
scheme?
We would have a new configure option: --with-incompatibl
At 08:43 PM 3/26/2003 +0100, Marcus Börger wrote:
Lets disallow both nesting function and NOT WORKING nested namespaces (and
classes?) for PHP5.
We changed a lot and took care about BC issues even more but why not get
rid of these shit? AND
why introducing even more nonsense?
I definitely don'
> That's a short list.
Concerning systems which have been phased out a long time
ago, even at organizations with strict policies. You
occassionally find a SunOS 4 box from 1990, but would you
integrate it into a web cluster? I don't think so.
Sharing session data over a netw
On Wednesday, March 26, 2003, at 02:46 PM, Shane Caraveo wrote:
Didn't figure you were, I'm simply arguing that it shouldn't be
allowed for either. It doesn't serve any usefull purpose and has
negative impact, and since this is a major version change, so we
should feel free to break a bit of B
Rasmus Lerdorf wrote:
On Wed, 26 Mar 2003, Shane Caraveo wrote:
Rasmus Lerdorf wrote:
Couldn't you make the same argument for:
function A() {
function B() {
}
}
I would :)
The syntax is meaningless and confusing if the program does not operate
the way it is written. By all sensible c
At 19:45 26.03.2003, Shane Caraveo wrote:
Rasmus Lerdorf wrote:
Couldn't you make the same argument for:
function A() {
function B() {
}
}
I would :)
The syntax is meaningless and confusing if the program does not operate
the way it is written. By all sensible considerations, B shoul
On Wed, 26 Mar 2003, Stanislav Malyshev wrote:
> Well, I don't know for the future and stuff. I talked with Andi and he
> agrees with you (i.e., he doesn't see a use in nested namespaces) so I
> would probably un-nest them.
>
> Also, I think that include() (and its brothers) should be not part o
>> > local to A. Since it is not, the syntax should cause a parser error,
>> > and the same with namespaces. And then what happens with that stuff
>> > when, at some point in the future, proper scoping is implemented?
Well, I don't know for the future and stuff. I talked with Andi and he
agre
On Wednesday, March 26, 2003, at 02:36 PM, Rasmus Lerdorf wrote:
On Wed, 26 Mar 2003, Shane Caraveo wrote:
Rasmus Lerdorf wrote:
Couldn't you make the same argument for:
function A() {
function B() {
}
}
I would :)
The syntax is meaningless and confusing if the program does not
op
On Wed, 26 Mar 2003, Shane Caraveo wrote:
> Rasmus Lerdorf wrote:
> > Couldn't you make the same argument for:
> >
> > function A() {
> > function B() {
> > }
> > }
>
> I would :)
>
> The syntax is meaningless and confusing if the program does not operate
> the way it is written.
On Wednesday, March 26, 2003, at 02:04 PM, Sascha Schumann wrote:
Or you implement a storage architecture that doesn't rely on
unreliably
implemented OS features.
George, I would appreciate some constructive messages from
you. This thread contained mostly FUD from your side.
That's pret
> Or you implement a storage architecture that doesn't rely on unreliably
> implemented OS features.
George, I would appreciate some constructive messages from
you. This thread contained mostly FUD from your side.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To
On Wednesday, March 26, 2003, at 01:52 PM, Sascha Schumann wrote:
Last I checked there were reliability problems with locking
implementations across NFS on many UNIXes.
Well, if you want to deploy a NFS-based web cluster, you will
very likely not choose some heterogeneous setup with
i
> Last I checked there were reliability problems with locking
> implementations across NFS on many UNIXes.
Well, if you want to deploy a NFS-based web cluster, you will
very likely not choose some heterogeneous setup with
incompatible NFS implementations.
As if that was not obviou
Stanislav Malyshev wrote:
DR>> But it *is* confusing (just as function() { function() {} }, but of
DR>> course we can not change that anymore). What is the reason of
DR>> allowing this 'nested' stuff?
Because someone asked for it. I don't see why it is so bad.
That's a bad reason for a bad feature
On Wed, 26 Mar 2003, Sascha Schumann wrote:
> > The syntax is meaningless and confusing if the program does not operate
> > the way it is written. By all sensible considerations, B should be
> > local to A. Since it is not, the syntax should cause a parser error,
> > and the same with namespaces
On Wednesday, March 26, 2003, at 01:31 PM, Sascha Schumann wrote:
There's also the problem of file locking on nfs mounts.
That's true for 3-5 year old Linux boxes.
Last I checked there were reliability problems with locking
implementations across NFS on many UNIXes.
Try running a prope
> The syntax is meaningless and confusing if the program does not operate
> the way it is written. By all sensible considerations, B should be
> local to A. Since it is not, the syntax should cause a parser error,
> and the same with namespaces. And then what happens with that stuff
> when, at s
On Wed, 26 Mar 2003, Shane Caraveo wrote:
> The syntax is meaningless and confusing if the program does not operate
> the way it is written. By all sensible considerations, B should be
> local to A. Since it is not, the syntax should cause a parser error,
> and the same with namespaces. And t
Rasmus Lerdorf wrote:
Couldn't you make the same argument for:
function A() {
function B() {
}
}
I would :)
The syntax is meaningless and confusing if the program does not operate
the way it is written. By all sensible considerations, B should be
local to A. Since it is not, the s
On Wed, 26 Mar 2003, Stanislav Malyshev wrote:
> Because someone asked for it. I don't see why it is so bad.
Heh, I've asked for a lot of things that didn't make it into the engine.
:) The badness of it is the confusion it will cause.
-Andrei http://www.gravi
On Wed, 26 Mar 2003, Rasmus Lerdorf wrote:
> Couldn't you make the same argument for:
>
> function A() {
> function B() {
> }
> }
>
> This has worked for years and both A() and B() become global functions.
Yes, but that's a remnant of the old syntax. We shouldn't introduce new
cruft
DR>> But it *is* confusing (just as function() { function() {} }, but of
DR>> course we can not change that anymore). What is the reason of
DR>> allowing this 'nested' stuff?
Because someone asked for it. I don't see why it is so bad.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTE
On Wed, 2003-03-26 at 13:35, Stanislav Malyshev wrote:
> SH>> I believe the way it was designed was:
> SH>>
> SH>> namespace A {
> SH>> namespace A:B {
> SH>>class C {
> SH>>}
> SH>> }
> SH>> }
>
> That's the same thing. As was noted repeatedly on the lists, ':' has no
>
On Wed, 26 Mar 2003, Stanislav Malyshev wrote:
> SH>> I believe the way it was designed was:
> SH>>
> SH>> namespace A {
> SH>> namespace A:B {
> SH>>class C {
> SH>>}
> SH>> }
> SH>> }
>
> That's the same thing. As was noted repeatedly on the lists, ':' has no
> semanti
SH>> I believe the way it was designed was:
SH>>
SH>> namespace A {
SH>> namespace A:B {
SH>>class C {
SH>>}
SH>> }
SH>> }
That's the same thing. As was noted repeatedly on the lists, ':' has no
semantic meaning, A and A:B are not related in any way.
One again:
Namespace
This is not the e-mail you are looking for... move along.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> There's also the problem of file locking on nfs mounts.
That's true for 3-5 year old Linux boxes.
Try running a proper NFS setup.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 2003-03-26 at 13:18, George Schlossnagle wrote:
> What is the value of that syntax? That seems entirely confiusing to
> me. If
>
> namespace A { namespace B {} }
>
I believe the way it was designed was:
namespace A {
namespace A:B {
class C {
}
}
}
-Sterling
On Wednesday, March 26, 2003, at 01:25 PM, Sascha Schumann wrote:
ack, that's awful! Session id's aren't unique across clusters of
machines. You'll risk session corruption.
They are not guranteed to be unique, even on a single host.
There's also the problem of file locking on nfs mounts.
On Wed, 2003-03-26 at 04:39, Antony Dovgal wrote:
> On Wed, 26 Mar 2003 01:30:11 -0800 (Pacific Standard Time)
> Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
>
> > I don't see how it is in any way exploitable.
> That's what I wanted to say indeed.
>
> IMHO it will be much better to move this extensi
> ack, that's awful! Session id's aren't unique across clusters of
> machines. You'll risk session corruption.
They are not guranteed to be unique, even on a single host.
Spreading your load across multiple machines actually
decreases the probability of a collision, because the
Couldn't you make the same argument for:
function A() {
function B() {
}
}
This has worked for years and both A() and B() become global functions.
-Rasmus
On Wed, 26 Mar 2003, Andrei Zmievski wrote:
> Care to explain a little more? I think allowing this syntax is very
> confusing f
On Wed, 2003-03-26 at 15:29, Antony Dovgal wrote:
> I just don't see any reasons to include experimental extensions,
> that will cause such "security advisories", into the core distribution.
> Someone can explain this to me, maybe I'm wrong?
The plan is to move a lot of extension to PECL, once th
What is the value of that syntax? That seems entirely confiusing to
me. If
namespace A { namespace B {} }
doesn't create a nested namespace, what is the value of having it?
On Wednesday, March 26, 2003, at 01:10 PM, Stanislav Malyshev wrote:
Noting to fix. This is by design.
AZ>> namespace
Care to explain a little more? I think allowing this syntax is very
confusing for the user.
I can see the point of this:
namespace A {
class B {
...
}
}
...
namespace A {
class C {
...
}
}
But not in the example below. People would basically expect to have
nested namespaces
This is not the list you are looking for. Please move this discussion
to php-general.
On Wednesday, March 26, 2003, at 10:51 AM, Ján Šuňavec wrote:
Thanks for that.
I think for Linux is better use --with-mm. But I use windows, and i
don't know compile PHP. Can you compile next PHP version w
Noting to fix. This is by design.
AZ>> namespace A {
AZ>> namespace B{
AZ>> class C {
AZ>> function D() { print "asdf\n"; }
AZ>> }
AZ>> }
AZ>>
AZ>> }
AZ>>
AZ>> B::C::D();
AZ>>
AZ>> Apparently, the parser allows nesting namespaces, but they are all
AZ>> regis
On Wednesday, March 26, 2003, 4:44:14 PM, Rudi Benkovic wrote:
> This little patch adds a fifth optional parameter for imap_append()
> which allows to set the internal IMAP date of the appended messages.
> It seems to work fine here... If anyone would care to commit it, that
> would be great.
Oh,
This is a conversation for php-general, not here.
But...
There are lts of good reasons to leave them
in files, one is that you can have an NFS volume that a group of
servers
can share letting you have the luxury of sessions behind a
loadbalancer.
ack, that's awful! Session id's aren't unique a
namespace A {
namespace B{
class C {
function D() { print "asdf\n"; }
}
}
}
B::C::D();
Apparently, the parser allows nesting namespaces, but they are all
registered as global ones. Should be fixed, I think.
-Andrei http:/
> > I'd really not love to see it :) Use an if-else chain of ===
> > comparisons
> > instead if that's what you really need.
>
> Oh, well, fair enough -- I can live with that, although I think it's a less
> elegant way of programming it. Still, nothing ventured nothing gained...!
> ;)
Mike, chan
You can do this your self using shared memory segments and custom
session handling functions. There are lts of good reasons to leave them
in files, one is that you can have an NFS volume that a group of servers
can share letting you have the luxury of sessions behind a loadbalancer.
On Wed, 2
Hi,
This little patch adds a fifth optional parameter for imap_append()
which allows to set the internal IMAP date of the appended messages.
It seems to work fine here... If anyone would care to commit it, that
would be great.
Thanks.
--
Rudi Benkovic [EMAIL PROTECTED]--- php_imap.c
On Wed, 2003-03-26 at 10:39, Antony Dovgal wrote:
> On Wed, 26 Mar 2003 01:30:11 -0800 (Pacific Standard Time)
> Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
>
> > I don't see how it is in any way exploitable.
> That's what I wanted to say indeed.
>
> IMHO it will be much better to move this extensi
On Wed, 26 Mar 2003 14:02:55 +0100
JАn ╘uРavec <[EMAIL PROTECTED]> wrote:
http://php.net/session
To use shared memory allocation (mm) for session storage configure PHP
--with-mm[=DIR] .
You're late. Check the manual for additional info.
--
Wbr,
Antony Dovgal aka tony2001 mailto:[EMAIL PROT
On 26 Mar 2003 14:38:36 +0100
Martin Jansen <[EMAIL PROTECTED]> wrote:
> So you are proposing to move sockets to PECL, because the extension
> will not attract that much interest there and thus the possible
> security issues will not be revealed so fast?
> I agree with that up to a certain point,
On 26 Mar 2003 14:38:36 +0100
Martin Jansen <[EMAIL PROTECTED]> wrote:
> So you are proposing to move sockets to PECL, because the extension
> will not attract that much interest there and thus the possible
> security issues will not be revealed so fast?
> I agree with that up to a certain point,
> -Original Message-
> From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
> Sent: 26 March 2003 16:42
> To: Ford, Mike [LSS]
> > > I'd really not love to see it :) Use an if-else chain of ===
> > > comparisons
> > > instead if that's what you really need.
> >
> > Oh, well, fair enough -- I c
Thanks for that.
I think for Linux is better use --with-mm. But I use windows, and i
don't know compile PHP. Can you compile next PHP version with this
switch on? After that users can set session.save_path=mm and use
session store in memory..
Akelavlk
> You can do this y
On Wed, Mar 26, 2003 at 02:02:55PM +0100, J?n ?u?avec wrote:
> Hi
>
> I have one idea. Store session data in memory instead file. It's fast
> when file. Yes I know when script is finish all data is delete. But
> this can be same like file session. But in memory.
There already are various ways t
Hi
I have one idea. Store session data in memory instead file. It's fast
when file. Yes I know when script is finish all data is delete. But
this can be same like file session. But in memory.
Akelavlk
== REKLAMA =
Vyrazne zlav
On Wed, Mar 26, 2003 at 11:07:15AM +0100, Timm Friebe wrote:
> After looking into it:
> * sybase-fetch-assoc.xml is OK the way it is
> * Added some examples to sybase-set-message-handler.xml
> * Corrected the statement "will fail" to "will produce a warning"
> and added an example to sybase-unbu
> -Original Message-
> From: Zeev Suraski [mailto:[EMAIL PROTECTED]
> Sent: 26 March 2003 01:47
> To: Ford, Mike [LSS]
>
> At 03:27 25/03/2003, Ford, Mike [LSS] wrote:
> >I'd love to see, say, case_identical for requesting an ===
> comparison, with
> >case continuing as befo
On Tue, 25 Mar 2003, Dan Kalowsky wrote:
>
> I'm not a follower of the comments generally, but I would believe that
> deletion of them is the last thing we want to happen.
Sometimes they are deleted because they were incorporated into the
documentation itself though.
Derick
--
translating the phpdocs to dutch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, 2003-03-23 at 18:26, Sander Roobol wrote:
> On Sun, Mar 23, 2003 at 03:37:03PM +0100, Timm Friebe wrote:
> > On Sun, 2003-03-23 at 11:48, Sander Roobol wrote:
> > > If you supply a unified diff, I'll commit it.
> >
> > OK. Attached is a unified diff - the three new files which need to be
--On Wednesday, March 26, 2003 09:33:35 +0100 Uwe Schindler
<[EMAIL PROTECTED]> wrote:
The problem is: sfio seems not to be compatible with Solaris 9. The error
comes from:
# include
in floatingpoint.h.
Can you report your findings to AT&T? They do take bug reports.
--
Larry Rosenman
On Wed, 26 Mar 2003 01:30:11 -0800 (Pacific Standard Time)
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> I don't see how it is in any way exploitable.
That's what I wanted to say indeed.
IMHO it will be much better to move this extension to PECL and to
avoid such articles, having bad influence on P
It isn't an overflow, in that particular case, but there are other parts
of the sockets extension where negative values can make their way to an
emalloc() call, and I suppose you could call that an integer overflow. I
don't see how it is in any way exploitable.
-Rasmus
On Wed, 26 Mar 2003, Anton
Hello, all
Mordred Labs advisory - Integer overflow in PHP socket_iovec_alloc()
function.
http://www.securitylab.ru/?ID=36819
IMHO it's not integer overflow, but using of nonexisting second
parameter, just try to call:
and you'll get segfault.
Take a look at this part of code:
ext/sockets/so
The problem is: sfio seems not to be compatible with Solaris 9. The error
comes from:
#include
in floatingpoint.h.
This contains only the definition of FILE*... But stdio-tag.tag is not
included into the sfio package, so
both definitions are different and the compiler do not like it.
I fixed th
Was a error in -I directive. But now the following error diplays:
bash-2.05$ CC=cc CFLAGS="-I/pangaea/install/sfio/include" ./configure
--prefix=/pangaea/PHP4 --with-nsapi=/pangaea/webserver
--with-sybase-ct=$SYBASE --without-mysql
...
bash-2.05$ make
/bin/sh /pangaea/install/php4-STABLE-200303
70 matches
Mail list logo
