register_long_arrays is removed from PHP6 according to PDM.
But in 5.1 register_long_arrays has default value "1".
Shouldn't it be changed to "0"?
Dmitry.
> -Original Message-
> From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 16, 2006 12:45 PM
> To: php-cvs@lists.
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.
ht for 6.0
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Pierre-Alain Joye" <[EMAIL PROTECTED]>;
Sent: Tuesday, March 14, 2006 8:59 AM
Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / NEWS
Pierre and all,
A while ago I suggested to add an UP
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 really needed, what 1-2 liners they can write to get
the sam
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
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 bindto socket context option.
Hi,
I was going to document this new feature but I have a question:
Does the
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
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
> hav
- Original Message -
derick Sat Jul 2 17:19:25 2005 EDT
Log:
- Overhauled selecting the correct timezone. The timezone set with
"date_timezone_set" override the TZ environment variable, which on its
turn
overrides the date.timezone setting. If none of the three is set, we
fallb
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
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 rephrase, if there are no ob
Hi Ilia,
when I saw this commit I gazed half a minute to understand why
there is a time_ in front. Later I realized that you have introduced
a namespace for time functions. This is a good idea still the name is
a bit confusing IMO :) Also I saw that you have added quite a long ago
time_nanosleep(
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,
>
> 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?
don't mix php allocated memory with externally allocated memory. if you
want to return a string from pgsql, y
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
(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?
Chris
--
PHP Internals - PHP Runtime Development Mai
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-
Uh, would be nice to check with me before making this patch..
On Sat, 12 Mar 2005, Andrey Hristov wrote:
> andreySat Mar 12 07:03:51 2005 EDT
>
> Modified files:
> /php-src NEWS
> /php-src/ext/pcre php_pcre.c php_pcre.h
> /php-src/main SAPI.c
>
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)
Hi Rasmus, noticed a proto problem with this commit.
You have the function proto returning an array:
> +/* {{{ proto array apache_reset_timeout(void)
but:
> + RETURN_FALSE;
and
> + RETURN_TRUE;
Change the proto to return bool?
Dave
--
PHP Internals - PHP Runtime Development Mailing List
T
Thanks :)
At 10:53 AM 8/24/2004 +1000, Dave Barr wrote:
Andi Gutmans wrote:
andiMon Aug 23 16:18:11 2004 EDT
Modified files:
/php-srcNEWS Log:
- NEWS
http://cvs.php.net/diff.php/php-src/NEWS?r1=1.1799&r2=1.1800&ty=u
Index: php-src/NEWS
diff -u php-src/NEWS:1.1799 php-src/N
Andi Gutmans wrote:
andiMon Aug 23 16:18:11 2004 EDT
Modified files:
/php-src NEWS
Log:
- NEWS
http://cvs.php.net/diff.php/php-src/NEWS?r1=1.1799&r2=1.1800&ty=u
Index: php-src/NEWS
diff -u php-src/NEWS:1.1799 php-src/NEWS:1.1800
--- php-src/NEWS:1.1799 Mon
> > 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
Sara Golemon wrote:
pollita Sat Aug 7 00:50:25 2004 EDT
Modified files:
/php-src/ext/standard basic_functions.c basic_functions.h
/php-src NEWS
Log:
New Functions inet_pton() and inet_ntop()
+#ifdef HAVE_INET_NTOP
+ PHP_FE(inet_ntop,
What about the change in order of some function names? Are you sure you
want to keep it this way?
At 08:03 AM 3/23/2004 +, Marcus Boerger wrote:
helly Tue Mar 23 03:03:12 2004 EDT
Modified files:
/php-srcNEWS
/php-src/ext/sqlite sqlite.c
/php-src/ext/sqlite/tests
Moriyoshi Koizumi wrote:
> Now's not the time though.
Now (before the PHP 5.0.0 RC1) is exactly the time.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internal
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 Sat, 31 Jan 2004, Moriyoshi Koizumi wrote:
> moriyoshi Sat Jan 31 17:36:34 2004 EDT
>
> Modified files:
> /php-src NEWS
> /php-src/ext/pcre php_pcre.c php_pcre.h
> Log:
> - Fix bug #27103 (preg_split('//u') incorrectly splits UTF-8 strings into octets)
Nevermind, I forgot I could just look at the compile log on snaps. Looks
like that's exactly the problem. I'll rename these methods to something
less conflicting.
-Sara
"Sara Golemon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm having to guess on the translation here, but
I'm having to guess on the translation here, but it's sounding like it
doesn't think mkdir is an element of php_stream_wrapper_ops. Although there
seems to be a mention of mkdir/rmdir as macros in there? Perhaps renaming
them to stream_mkdir/stream_rmdir will keep windows happy.
Can you translat
Sara Golemon wrote:
pollita Fri Dec 12 23:07:19 2003 EDT
Modified files:
/php-src/main php_streams.h
/php-src/main/streams streams.c plain_wrapper.c userspace.c
/php-src/ext/standard file.c ftp_fopen_wrapper.c
http_fopen_wrapper.c ph
Ilia Alshanetsky wrote:
> +typedef struct yy_buffer_state *YY_BUFFER_STATE;
> +
> +#include "zend.h"
> +#include "zend_language_scanner.h"
> +#include "zend_language_parser.h"
On my Linux laptop basic_functions.c is compiled before the
zend_language_{scanner|parser}.h files are created.
--
S
> As Andi might say: "Why not call this http_headers()?" :)
> (and also rename 'headers_sent' -> http_headers_sent() :)
>
> --Jani
>
As you can probably guess, my answer to your first question is your second
question.
headers_sent() already exists and is in the same general grouping as
> > > Please use the naming conventions using a prefix. Maybe in this case
str_
> > > or mime_
> >
> >Does uu_* sound acceptable?
>
> It's better and I haven't been able to think of something better. It would
> be smarter in the long run if we though of some generic prefix which we
> could move all
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
Derick Rethans wrote:
> derickSat Aug 16 16:55:28 2003 EDT
>
> Added files:
> /php-src/ext/standard/tests/time bug17988.phpt
>
> Modified files:
> /php-src/ext/standard parsedate.y
> /php-src NEWS
> Log:
> - Fixed bug #17988: strtotime fails to parse timest
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
Sterling Hughes wrote:
> sterling Wed Jun 25 00:39:01 2003 EDT
>
> Modified files:
> /php-src NEWS
> Log:
> add zend engine 2 changes.
I think ZEND_CHANGES should be merged into NEWS.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpen
Sterling Hughes wrote:
> +- Due to a license change, we are longer bundling
^
+no :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
http://www.professionelle-softwareentwicklung-mit-php5.de/
--
P
87 matches
Mail list logo
