Pierre wrote:
> On Tue, 14 Mar 2006 07:32:15 -0800
> [EMAIL PROTECTED] (Andi Gutmans) wrote:
>
>> Yeah that sounds good. Maybe change UPDATE to UPDATING
>
> First draft commited in:
>
> php-src / README.UPDATING_TO_PHP6
>
> --Pierre
>
Hi,
A few remarks:
This code lacks the emulation for GET
On Tue, 14 Mar 2006 07:32:15 -0800
[EMAIL PROTECTED] (Andi Gutmans) wrote:
> Yeah that sounds good. Maybe change UPDATE to UPDATING
First draft commited in:
php-src / README.UPDATING_TO_PHP6
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> That's obviously not what I meant... but I've been in situations
> where there were LANs which were inaccessible by outside sources...
Do you know that most of the security or attacks problems come from
coworkers? :)
--Pierre
--
PHP Internal
That's obviously not what I meant... but I've been in situations
where there were LANs which were inaccessible by outside sources...
Never mind.. Not worth the discussion :)
Andi
At 07:35 AM 3/14/2006, Rasmus Lerdorf wrote:
Andi Gutmans wrote:
At 07:13 AM 3/14/2006, Pierre wrote:
Intranet a
Andi Gutmans wrote:
At 07:13 AM 3/14/2006, Pierre wrote:
Intranet apps does not need to be secure? That's new to me.
Depends what it is. A lot have to be secure, but some don't. For
example, some apps are on local networks (for example a group Wiki),
which are inaccessible outside a specific
On 3/14/06, Pierre <[EMAIL PROTECTED]> wrote:
> On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
> > >We agree on that, yes. I was even in the first to ask for migration
> > >docs. However a migration doc is not supposed to document how to keep
> > >doing things badly.
> >
> > Well at least do
Yeah that sounds good. Maybe change UPDATE to UPDATING
Thanks!
At 07:30 AM 3/14/2006, Pierre wrote:
On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> >We agree on that, yes. I was even in the first to ask for migration
> >docs. However a migration doc is not supposed to document how to kee
On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> >We agree on that, yes. I was even in the first to ask for migration
> >docs. However a migration doc is not supposed to document how to keep
> >doing things badly.
>
> Well at least document the first part and I'll make sure the second
> happe
At 07:13 AM 3/14/2006, Pierre wrote:
On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> At 06:28 AM 3/14/2006, Pierre wrote:
> >On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > > Pierre and all,
> > >
> > > A while ago I suggested to add an UPGRADING file for the PHP 6
> > > upgrade, wh
On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> At 06:28 AM 3/14/2006, Pierre wrote:
> >On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > > Pierre and all,
> > >
> > > A while ago I suggested to add an UPGRADING file for the PHP 6
> > > upgrade, where we'd document every time we break B
At 06:28 AM 3/14/2006, Pierre wrote:
On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Pierre and all,
>
> A while ago I suggested to add an UPGRADING file for the PHP 6
> upgrade, where we'd document every time we break BC and how to solve
> that. For example, with nuking register_globals we
On 3/14/06, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Pierre and all,
>
> A while ago I suggested to add an UPGRADING file for the PHP 6
> upgrade, where we'd document every time we break BC and how to solve
> that. For example, with nuking register_globals we could write what
> we broke, and if re
Someone upgrading from 4.4 to 6.0 would then have to work through a ton of
guides obviously. I guess there may be something that get reverted in
between (like E_STRICT on var), but those should be rare. There could of
course be improvements to changes or ease previous BC breaks. So of course
th
Where would you want to start UPGRADING from?
I think realistically to keep the work somewhat manageable we should focus
on providing disjunct steps.
4.4 -> 5.0
5.0 -> 5.1
..
5.y -> 6.0
If we find we have more resources to invest into this, we can inline some
of the hints from previous guid
Lukas Smith wrote:
Steph Fox wrote:
Where would you want to start UPGRADING from?
The main problem I faced with the 5.1.0 version was not knowing how
far back to go... or what to count 'in'. E.g. something that was only
in CVS for a few weeks and no releases - should that be included?
Needs
Steph Fox wrote:
Where would you want to start UPGRADING from?
The main problem I faced with the 5.1.0 version was not knowing how far
back to go... or what to count 'in'. E.g. something that was only in CVS
for a few weeks and no releases - should that be included?
Needs some thought for 6.
Where would you want to start UPGRADING from?
The main problem I faced with the 5.1.0 version was not knowing how far back
to go... or what to count 'in'. E.g. something that was only in CVS for a
few weeks and no releases - should that be included?
Needs some thought for 6.0
- Orig
Indeed, ftp:// doesn't use the transports layer at all. I'll patch this
up
-Sara
""Nuno Lopes"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> OK. but at least it could work with 'x.x.x.x:0'. From I what I remember
from
> the code, it always uses NULL as bindto when calling
>
OK. but at least it could work with 'x.x.x.x:0'. From I what I remember from
the code, it always uses NULL as bindto when calling
php_network_connect_socket_to_host().
Nuno
- Original Message -
FTP creates two socket connections during normal operation; it will
attempt to bind both
FTP creates two socket connections during normal operation; it will
attempt to bind both to the port you specified.
--Wez.
On 7/13/05, Nuno Lopes <[EMAIL PROTECTED]> wrote:
> Well I've tested again and it works also with the 'tcp' wrapper, but not
> with ftp.
>
> consider this:
> $bogus = strea
Well I've tested again and it works also with the 'tcp' wrapper, but not
with ftp.
consider this:
$bogus = stream_context_create(array('socket'=>array('bindto' =>
"1.2.3.1:5000")));
echo
file_get_contents('http://darkstar.ist.utl.pt/gentoo/snapshots/portage-20050712.tar.bz2.md5sum',
NULL, $bo
It is not a wrapper specific context option, it'll work with any TCP/IP
socket.
Ilia
Nuno Lopes wrote:
iliaa Mon Jun 13 22:39:43 2005 EDT
Modified files:
/php-src/main network.c php_network.h
/php-src/main/streams xp_socket.c
/php-src/ext/ftp ftp.c
/php-src NEWS
Log:
Added bind
At 10:25 PM 7/4/2005 +0200, Derick Rethans wrote:
On Mon, 4 Jul 2005, Mike Robinson wrote:
> date_timezone_default_set <-- Can you use this, which seems like the
proper name,
> date_tz_default_set <-- then alias this to it?
We can, but adding an alias when introducting a function do
On Mon, 4 Jul 2005, Mike Robinson wrote:
> date_timezone_default_set <-- Can you use this, which seems like the proper
> name,
> date_tz_default_set <-- then alias this to it?
We can, but adding an alias when introducting a function doesn't make
sense. date_timezone_default_set it wil
Derick Rethans wrote:
> date_timezone_default_set <-- Can you use this, which seems like the
proper name,
> date_tz_default_set <-- then alias this to it?
Best,
Mike Robinson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.
On Mon, 4 Jul 2005 14:56:41 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Mon, 4 Jul 2005, Pierre-Alain Joye wrote:
>
> > I was not :) but still remains TS issues and inconsistencies
> > between OSes.
>
> Don't forget the thread safety issues...
>
> > In short, we need this functi
On Mon, 4 Jul 2005 14:10:42 +0100
[EMAIL PROTECTED] ("Nuno Lopes") wrote:
> > On Mon, 4 Jul 2005, Pierre-Alain Joye wrote:
> >
> >> I was not :) but still remains TS issues and inconsistencies
> >> between OSes.
> >
> > Don't forget the thread safety issues...
> >
> >> In short, we need this fu
On Mon, 4 Jul 2005, Pierre-Alain Joye wrote:
I was not :) but still remains TS issues and inconsistencies
between OSes.
Don't forget the thread safety issues...
In short, we need this function, we can move to the name choice
now :)
date_timezone_default_set
date_tz_default_set
date_default
On Mon, 4 Jul 2005, Pierre-Alain Joye wrote:
> I was not :) but still remains TS issues and inconsistencies
> between OSes.
Don't forget the thread safety issues...
> In short, we need this function, we can move to the name choice
> now :)
date_timezone_default_set
date_tz_default_set
date_defa
On Mon, 4 Jul 2005, Nuno Lopes wrote:
> > TZ Env is painfull. Not always (or always not?) thread safe. Ini
> > settings cannot be changed in safe mode.
>
> Are you sure?
It doesn't matter. We don't want to rely on TZ's and there is a
possibility that ini_set doesn't work. Therefore it should be
On Mon, 4 Jul 2005 13:44:29 +0100
"Nuno Lopes" <[EMAIL PROTECTED]> wrote:
> Are you sure?
I was not :) but still remains TS issues and inconsistencies
between OSes.
In short, we need this function, we can move to the name choice
now :)
--Pierre
--
PHP Internals - PHP Runtime Development Mai
>> Last point, can you rename date_timezone_* to
>> date_default_timezone_*?
>
> Yes, but it's too long. Can we come up with something better?
>
> Derick
Sorry, but I still didn't understand why the need for those
functions.. You can change the precendence in the TZ guess
internal function and yo
On Mon, 4 Jul 2005 13:32:28 +0100
[EMAIL PROTECTED] ("Nuno Lopes") wrote:
> >> Last point, can you rename date_timezone_* to
> >> date_default_timezone_*?
> >
> > Yes, but it's too long. Can we come up with something better?
> >
> > Derick
>
> Sorry, but I still didn't understand why the need for
Last point, can you rename date_timezone_* to
date_default_timezone_*?
Yes, but it's too long. Can we come up with something better?
Derick
Sorry, but I still didn't understand why the need for those functions..
You can change the precendence in the TZ guess internal function and you can
dro
On Mon, 4 Jul 2005 14:16:53 +0200 (CEST)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> > The Oslon's database changes (rarely but does :).
>
> It actually does about once a month...
I meant the amount of usefull changes. I can see some advantages to
move the TZ as an extension. It can contains onl
On Mon, 4 Jul 2005, Pierre-Alain Joye wrote:
> The Oslon's database changes (rarely but does :).
It actually does about once a month...
> People also like
> to have some datas that are not or will not be in the Oslon's db.
> We can either reject to add datas that will not be in the Oslon's
> db
On Mon, 4 Jul 2005 13:52:24 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> The database can not be editable this easily, but that should not
> be needed anyway.
No it's not that easy to make it editable. It should have been
easier using hashtables or other methods.
> For aliases, these
On Mon, 4 Jul 2005, Pierre-Alain Joye wrote:
> For now I will focus on my pecl work. I suspended my commits and my
> new things on Derick's demand, was maybe not a good idea, but it's
> too late now ;). The only thing I will use from timelib is the TZ
> database. But it needs to be editable, allow
On Mon, 4 Jul 2005 11:48:06 +0100
"Nuno Lopes" <[EMAIL PROTECTED]> wrote:
> >> So, you can give precedence to the ini option over the TZ var.
> >> That way you don't need the functions.
> >> IMHO this is the better choice, as it allows you to set a site
> >> wide ini option, without touching in th
So, you can give precedence to the ini option over the TZ var.
That way you don't need the functions.
IMHO this is the better choice, as it allows you to set a site
wide ini option, without touching in the environment vars or
having to call a function in each script.
If there was not a BC proble
On Mon, 4 Jul 2005, Xuefer wrote:
> FYI:
> http://bugs.php.net/?id=33545
> i use cygwin for local test
> date() make me crazy as it gives out warning all over the php pages
>
> imho, the precendence should change too.
I'm not going to change it because of BC reasons.
Derick
--
Derick Rethans
FYI:
http://bugs.php.net/?id=33545
i use cygwin for local test
date() make me crazy as it gives out warning all over the php pages
imho, the precendence should change too.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, 3 Jul 2005 13:38:38 +0100
[EMAIL PROTECTED] ("Nuno Lopes") wrote:
> So, you can give precedence to the ini option over the TZ var.
> That way you don't need the functions.
> IMHO this is the better choice, as it allows you to set a site
> wide ini option, without touching in the environmen
On Sun, 3 Jul 2005, Nuno Lopes wrote:
Hi Derick et all,
I think that having the date_timezone_set() and date_timezone_get()
functions
along with the default_timezone ini option is redundant. You can use
ini_set()/ini_get() to emulate the functions you added. I don't see a
point to
have 3 wa
Ilia Alshanetsky wrote:
Andrey Hristov wrote:
Because both functions are in HEAD and still the API is not released
I would appreciate if time_nanosleep() is renamed to nanosleep().
time_sleep_until() "emulate" a system function but uses it and in this
case maybe the name may stay the same.
To reph
Christopher Kings-Lynne wrote:
take a look at the RETURN_STRING[L] macro. the last argument
determines
whether the string passed to it is duplicated by PHP before returning
it to the user.
But if you return and duplicate, you have no chance to free() the
original string, no?
Ah, I see your
If you really don't want to estrndup it for some reason, you are going
to need to return a resource and manage that memory yourself through a
set of access functions.
Well, it would be nice to be able to avoid having to strcpy large binary
database objects...
I guess I was thinking that there m
Christopher Kings-Lynne wrote:
(Reposted to correct list - can someone help here?)
I want to return a string allocated by the postgresql library. However,
PHP ends up efree()ing it I think, which causes a miscount error. How
can I deal with this?
What can I do about this?
If you really don't w
take a look at the RETURN_STRING[L] macro. the last argument determines
whether the string passed to it is duplicated by PHP before returning it to
the user.
But if you return and duplicate, you have no chance to free() the
original string, no?
Chris
--
PHP Internals - PHP Runtime Developmen
Christopher Kings-Lynne wrote:
(Reposted to correct list - can someone help here?)
I want to return a string allocated by the postgresql library. However,
PHP ends up efree()ing it I think, which causes a miscount error. How
can I deal with this?
What can I do about this?
I'm not sure what exa
I guess it's fine. I would make sure, though, that you can pass NULL for
that parameter safely, in case we add another one in the future and you
don't need to get the replacement count.
On Tue, 15 Mar 2005, Andrey Hristov wrote:
> Hi Andrei,
> do you have anything against that change?
>
> Cheers
Don't interrupt me when I'm talking to myself!
-Andrei
On Mar 15, 2005, at 4:14 PM, Rasmus Lerdorf wrote:
Andrey, Andrei, what's the difference? Andre[iy] is the PCRE guy.
Andrey Hristov wrote:
Hi Andrei,
do you have anything against that change?
Cheers,
Andrey
Andrei Zmievski wrote:
Uh, would be
Andrey, Andrei, what's the difference? Andre[iy] is the PCRE guy.
Andrey Hristov wrote:
Hi Andrei,
do you have anything against that change?
Cheers,
Andrey
Andrei Zmievski wrote:
Uh, would be nice to check with me before making this patch..
--
PHP Internals - PHP Runtime Development Mailing List
Hi Andrei,
do you have anything against that change?
Cheers,
Andrey
Andrei Zmievski wrote:
Uh, would be nice to check with me before making this patch..
On Sat, 12 Mar 2005, Andrey Hristov wrote:
andrey Sat Mar 12 07:03:51 2005 EDT
Modified files:
/php-src NEWS
/php-
If all return paths return bool, then yes. Otherwise, no. (now that's a
boolean way to put it :)
Andi
At 09:09 PM 12/4/2004 +1100, Dave Barr wrote:
Hi Rasmus, noticed a proto problem with this commit.
You have the function proto returning an array:
> +/* {{{ proto array apache_reset_timeout(void)
> > I fixed it by moving the arpa/inet.h include above the php_standard.h
> > include, but I'm not sure if this would be the correct solution.
> >
>
> Hmm this doesn't work either as it makes the PHP function name
> __inet_ntop().
>
I just committed what should be a fix. If it still mangles the us
Dave Barr wrote:
I fixed it by moving the arpa/inet.h include above the php_standard.h
include, but I'm not sure if this would be the correct solution.
Hmm this doesn't work either as it makes the PHP function name
__inet_ntop().
Dave
--
PHP Internals - PHP Runtime Development Mailing List
To u
On Tue, 03 Feb 2004, Moriyoshi Koizumi wrote:
> >Would you please run changes like these by me in the future before
> >committing them?
>
> Sure. BTW was there anything wrong with it? If so, I'm gonna revert it
> then.
Nothing wrong per se, I've just been trying to think of a better way to
do it
On 2004/02/03, at 3:44, Andrei Zmievski wrote:
- Fix bug #27103 (preg_split('//u') incorrectly splits UTF-8
strings into octets).
Would you please run changes like these by me in the future before
committing them?
Sure. BTW was there anything wrong with it? If so, I'm gonna revert it
then.
Mo
On Sun, 17 Aug 2003, Sebastian Bergmann wrote:
> Derick Rethans wrote:
> > derick Sat Aug 16 16:55:28 2003 EDT
> >
> > Added files:
> > /php-src/ext/standard/tests/timebug17988.phpt
> >
> > Modified files:
> > /php-src/ext/standard parsedate.y
> > /php-src
On Wed, 2003-06-25 at 00:41, Sebastian Bergmann wrote:
> Sterling Hughes wrote:
> > sterlingWed Jun 25 00:39:01 2003 EDT
> >
> > Modified files:
> > /php-srcNEWS
> > Log:
> > add zend engine 2 changes.
>
> I think ZEND_CHANGES should be merged into NEWS.
>
Its way
61 matches
Mail list logo
