The behavior in 5.3 is actually more correct then in 5.2. In 5.3 we
only skip # on the first line if it is followed by ! indicating its an
instruction to execute some binary. In 5.2 on the other hand 1st line
starting with # is skipped, which is not entirely correct.
Ilia Alshanetsky
O
CLI
-Hannes
On Sun, Apr 19, 2009 at 18:21, Ilia Alshanetsky wrote:
> Are you using CGI or CLI sapi?
>
> Ilia Alshanetsky
>
>
>
>
> On 19-Apr-09, at 12:16 PM, Hannes Magnusson wrote:
>
>> I'm pretty sure yes.
>> Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests with
>> it.
>> Th
Are you using CGI or CLI sapi?
Ilia Alshanetsky
On 19-Apr-09, at 12:16 PM, Hannes Magnusson wrote:
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests
with it.
Then diff the run-tests to see the workaround in 5.3.
-Hannes
On Sun, Apr 19, 2009 at 17:
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests with it.
Then diff the run-tests to see the workaround in 5.3.
-Hannes
On Sun, Apr 19, 2009 at 17:57, Ilia Alshanetsky wrote:
> Last I checked it was working properly, are you sure you are using the
> latest
Last I checked it was working properly, are you sure you are using the
latest version? I think we even have a test case around this bug.
Ilia Alshanetsky
On 19-Apr-09, at 7:09 AM, Hannes Magnusson wrote:
On Sat, Apr 18, 2009 at 23:48, Nuno Lopes wrote:
The original code actually can be
On Sat, Apr 18, 2009 at 23:48, Nuno Lopes wrote:
The original code actually can be found inside php_cli.c and there it
only checked the 1st line for '#'. if you create a file such as:
#1
#2
>>
>>> The issue here is that the old code only looked at the main script, now
>>>
The original code actually can be found inside php_cli.c and there it
only checked the 1st line for '#'. if you create a file such as:
#1
#2
The issue here is that the old code only looked at the main script, now
included files ar affected, too.
So either we check in the scanner whether this is
On Fri, Jan 2, 2009 at 00:40, Johannes Schlüter wrote:
> On Thu, 2009-01-01 at 15:46 -0500, Ilia Alshanetsky wrote:
>> Nuno,
>>
>> The original code actually can be found inside php_cli.c and there it
>> only checked the 1st line for '#'. if you create a file such as:
>> #1
>> #2
>>
> The issue h
Dmitry Stogov wrote:
Is this Zend extensions only?
Yes.
Is it safe to set in extensions that should
work with pre 5.3 PHP's?
Yes, in php5.2 and below build_id just won't be checked ans this
callback won't be called.
Did I lose track of the other API versioning change - the one that was
Christopher Jones wrote:
Stanislav Malyshev wrote:
Hi!
I'm looking forward to reading at least a mail note describing what
extension
maintainers can/can't do with this.
Basically you can make your Zend extension load with any API number
and any build ID (or let it decide with which ID
Stanislav Malyshev wrote:
Hi!
I'm looking forward to reading at least a mail note describing what
extension
maintainers can/can't do with this.
Basically you can make your Zend extension load with any API number and
any build ID (or let it decide with which ID to load and with which one
Hi Dmitry,
I had looked at this Bug and wondering whether it should be fixed (I guess
the answer is yes :-)) and how to do so. I was only thinking along the
lines of adding a stack to keep track of multiple heredocs in the scanner.
Then I saw your fix and thought it was a cool method and bett
Hello Etienne,
Friday, August 8, 2008, 9:54:49 PM, you wrote:
> Hello,
> On Fri, Aug 8, 2008 at 9:50 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>>> helly Fri Aug 8 17:10:49 2008 UTC
>>>
>>> M
On Fri, Aug 8, 2008 at 21:54, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Forgot to mention it: there is something weird in mysqli_driver.c, I
> don't know what the author's original intention was, but it looks
> wrong.
> c.f. FIXME
I think I already filed a bug report about that some months ago,
Hello,
On Fri, Aug 8, 2008 at 9:50 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
>> helly Fri Aug 8 17:10:49 2008 UTC
>>
>> Modified files:
>>/php-src/main main.c php.h
>>/ZendEngine2
Hello,
On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> helly Fri Aug 8 17:10:49 2008 UTC
>
> Modified files:
>/php-src/main main.c php.h
>/ZendEngine2zend.h zend_API.c zend_execute_API.c zend_vm_def.h
>zend_vm_ex
Hello Lukas,
Sunday, July 27, 2008, 12:00:55 PM, you wrote:
> On 27.07.2008, at 02:58, Marcus Boerger wrote:
>> Hello Internals,
>>
>> apparently overloaded objects do not need to implement property
>> access
>> and we issue an E_NOTICE in case someone tries to none-the-less.
>> Dmirty
>>
On 27.07.2008, at 02:58, Marcus Boerger wrote:
Hello Internals,
apparently overloaded objects do not need to implement property
access
and we issue an E_NOTICE in case someone tries to none-the-less.
Dmirty
thankfully made this consistent for all handlers now. However this
raised a
ques
Marcus Boerger kirjoitti:
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we
Marcus Boerger escribió:
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we s
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we should increase the severity
On Sat, 5 Jul 2008, Rui Hirokawa wrote:
> Thank you for bug report.
> I found a very sinple scipt (t1.php, shown below)
> causes segmentation error or stack error
> using PHP 5.3 compiled with --enable-zend-multibyte.
> It works fine with PHP 5.2.
My script was malfunctioning with PHP 5.2 as well
Derick,
Thank you for bug report.
I found a very sinple scipt (t1.php, shown below)
causes segmentation error or stack error
using PHP 5.3 compiled with --enable-zend-multibyte.
It works fine with PHP 5.2.
php.ini
---
mbstring.internal_encoding = UTF-8
mbstring.script_encoding = SJIS
--
t1.php
On Sun, 29 Jun 2008, Rui Hirokawa wrote:
> hirokawa Sun Jun 29 08:21:36 2008 UTC
>
> Modified files: (Branch: PHP_5_3)
> /ZendEngine2 Zend.m4 zend.c zend_compile.c zend_globals.h
> zend_highlight.c zend_language_scanner.c
>
Stanislav Malyshev wrote:
Hi!
How can it break existing code? It's only on issue if a class is part
of a namespace, and existing code doesn't have namespaces. So it
*can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy t
Hello Stanislav,
I must be having a headache here. But there seriously seems to be a
misunderstanding.
We definitively introduced __construct as a bug fix in our language design.
And that is that you can have a function a in your class b that suddenly
becomes a constructor in the derived class
On 5/5/08, Pierre Joye <[EMAIL PROTECTED]> wrote:
> We can then even drop the old form in php 6.x. Many changes have no
> gain but make the language clearer or cleaner. It is not an objective
> change but it does help to cleanup the language.
>
> I will not die if we still support old things fo
On Mon, May 5, 2008 at 9:18 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
>
> > kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3 and
> remove in PHP 6.x.
> >
>
> There's nothing to fix, it's not broken.
Ok, point made. Once again a "you vs all other" thread, no
Hi!
kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3
and remove in PHP 6.x.
There's nothing to fix, it's not broken.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runti
Hi!
We can then even drop the old form in php 6.x. Many changes have no
gain but make the language clearer or cleaner. It is not an objective
change but it does help to cleanup the language.
There's nothing to "cleanup". You trying to prove that this form should
be removed by representing it
On 05.05.2008, at 20:51, Pierre Joye wrote:
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
It's just simple to make constructors work in the same way in
namespaces and
out of them. It would be difficult to explain why the first script
prints
"ok" and the second do
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> It's just simple to make constructors work in the same way in namespaces and
> out of them. It would be difficult to explain why the first script prints
> "ok" and the second doesn't.
It is easy to explain: "You have to use
It's just simple to make constructors work in the same way in namespaces
and out of them. It would be difficult to explain why the first script
prints "ok" and the second doesn't.
I think, we must support old-style constructors for both cases or remove
them at all, but as I said removing t
Hi!
code should be updated to use the normal constructor (which exists
since 4-5 years).
There's nothing "not normal" about using either form of constructors,
why force people to rewrite their perfectly good and working code?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
Hi!
How can it break existing code? It's only on issue if a class is part of
a namespace, and existing code doesn't have namespaces. So it *can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy to do. Forcing people to rena
On Mon, 5 May 2008, Dmitry Stogov wrote:
> As we didn't drop this support yet, and it didn't work in namespaces by
> mistake I've fixed it to work in the same way as without namespaces.
>
> Removing this support won't give any speedup (except of compilation speed),
> but might break a lot of code
Hi Dmitry,
On Mon, May 5, 2008 at 8:02 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> As we didn't drop this support yet, and it didn't work in namespaces by
> mistake I've fixed it to work in the same way as without namespaces.
>
> Removing this support won't give any speedup (except of compilat
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation
speed), but might break a lot of code.
Thanks. Dmitry.
Antony Dovgal wrote:
On 05.
Hi!
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
If by old-style ctors you mean this:
namespace Foo;
class Bar {
function Bar() {/* ctor! */}
}
then I think it should be su
Pierre Joye escribió:
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
--
"Progress is possible only if we train ourselves to think about programs
without thinking of them as pieces o
On 05.05.2008 14:13, Derick Rethans wrote:
Support for old-style constructors in namespaces
Do we really want/need this?
I'm not really sure either.
5.3 seems to be perfect candidate for dropping this kind of backward
compatibility.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime
On Mon, May 5, 2008 at 12:13 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Mon, 5 May 2008, Dmitry Stogov wrote:
>
> > dmitryMon May 5 09:44:07 2008 UTC
> >
> > Added files:
> > /ZendEngine2/testsns_063.phpt
> >
> > Modified files:
> > /ZendEngine2
On Mon, 5 May 2008, Dmitry Stogov wrote:
> dmitryMon May 5 09:44:07 2008 UTC
>
> Added files:
> /ZendEngine2/testsns_063.phpt
>
> Modified files:
> /ZendEngine2 zend_API.c zend_compile.c
> Log:
> Support for old-style
On Thu, 17 Apr 2008, Dmitry Stogov wrote:
> Another idea: In case xdebug overwrites zend_execute() it can set
> EG(return_value_ptr_ptr) to point to some local variable then call original
> executor and then print pass return_value to caller or destroy it dependent on
> previous value of EG(return
Another idea: In case xdebug overwrites zend_execute() it can set
EG(return_value_ptr_ptr) to point to some local variable then call
original executor and then print pass return_value to caller or destroy
it dependent on previous value of EG(return_value_ptr_ptr).
Thanks. Dmitry.
Derick Retha
On Fri, 11 Apr 2008, Dmitry Stogov wrote:
> Sorry, but I think mainly about PHP performance, and of course I didn't know
> that you trace return_values it in xdebug.
>
> After the patch, in case if return value is not used we set
> EG(return_value_ptr_ptr) to NULL before call to nested execute().
Hi Derick,
Sorry, but I think mainly about PHP performance, and of course I didn't
know that you trace return_values it in xdebug.
After the patch, in case if return value is not used we set
EG(return_value_ptr_ptr) to NULL before call to nested execute().
I assume you can just check for (EG(
On Fri, 11 Apr 2008, Dmitry Stogov wrote:
> dmitryFri Apr 11 09:43:31 2008 UTC
>
> Modified files: (Branch: PHP_5_3)
> /php-src NEWS
> /ZendEngine2 zend.c zend_execute_API.c zend_vm_def.h
> zend_vm_execute.h
> Log:
> Optimi
Thanks Dmitry!
- Original Message -
From: "Dmitry Stogov" <[EMAIL PROTECTED]>
To: "Steph Fox" <[EMAIL PROTECTED]>
Cc: "internals"
Sent: Wednesday, March 12, 2008 8:54 AM
Subject: [PHP-DEV] RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5
Sorry for dealy.
It must be fixed now.
Thanks. Dmitry.
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 10, 2008 7:26 PM
> To: Dmitry Stogov
> Cc: internals
> Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /
> zend_API.c zend_builtin_funct
Steph Fox wrote:
> Hi Dmitry,
>
> I finally got around to upgrading my compiler over the weekend, but I
> still have to fiddle with line 229 of zend_execute.h to get sane nmake
> output in the 5_3 branch. And I'm not alone - see
> http://snaps.php.net/win32/snapshot-5.3.log, now it's back up. The
Hi Dmitry,
I finally got around to upgrading my compiler over the weekend, but I still
have to fiddle with line 229 of zend_execute.h to get sane nmake output in
the 5_3 branch. And I'm not alone - see
http://snaps.php.net/win32/snapshot-5.3.log, now it's back up. The only
place it doesn't th
On Tue, 12 Feb 2008, Andi Gutmans wrote:
> It's really hard to remember this stuff.
> Maybe we should make the system actually validate the messages when they
> are committed and reject the commit when tags are missing. For commits
> where a certain tag isn't relevant we could have an explicit way
t that way it's in the back (and front) of
people's mind :)
Andi
> -Original Message-
> From: Jani Taskinen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 12, 2008 10:31 AM
> To: Hannes Magnusson
> Cc: PHP Development
> Subject: Re: [PHP-DEV] Re: [ZEN
On Feb 12, 2008 7:47 PM, Hannes Magnusson <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 7:35 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> > On Feb 12, 2008 7:31 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> > >
> > > I myself have forgot to use the damn dog tag many times. (Which is it
> > > again,
On Feb 12, 2008 7:35 PM, Pierre Joye <[EMAIL PROTECTED]> wrote:
> On Feb 12, 2008 7:31 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> >
> > I myself have forgot to use the damn dog tag many times. (Which is it
> > again, @DOC@ or [DOC] ? :) And if I forget, I'd like to be reminded.
>
> Same here, I
On Feb 12, 2008 7:31 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> Please, when you give such feedback, please point finger at the persons
> who deserve it. Now it feels like everyone is "misbehaving" here.
> Not only mention the name in the body of the email but Cc: the mail to
> these people. Ea
Please, when you give such feedback, please point finger at the persons
who deserve it. Now it feels like everyone is "misbehaving" here.
Not only mention the name in the body of the email but Cc: the mail to
these people. Each and everyone who deserves to get spanked. And I'm not
joking..
I mysel
I would really really really really appreciate if the [DOC] tag was used more.
While only random new features (or whatever requiring docs) are tagged
with [DOC] it is totally useless as the doc team still has to browse
through every single commit to figure out if there is something in it
to docume
Hi Marcus,
It's not a real problem to break the win32 build because it's a very simple
fix, but it'd still be kinda nice if the PHP_5_3 checkout would just build
without manual assistance. Snaps would work an' everything.
Please fix last_scope declaration, mini-patch attached.
- Steph
-
I don't see why allocated memory shouldn't be properly initialized in
the first place. To me this looked like a bug in the engine because all
I'd guess for the same reason all C allocators don't initialize memory
unless explicitly asked to - because it costs performance.
Secondly, if the eng
On Mon, 19 Nov 2007, Dmitry Stogov wrote:
> Do you really like to slowdown compilation to support some buggy
> extension? zend_extension_op_array_ctor_handler(s) must be used to
> setup "reserved" data.
I don't see why allocated memory shouldn't be properly initialized in
the first place. To m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2007, at 08:06:20, Jani Taskinen wrote:
Sorry for the top posting Derick. :)
Stas, this patch solves the problems with @ and doing
"php_admin_value error_reporting ":
http://pecl.php.net/~jani/patches/zend_alter_ini_entry.patch
Very n
> -Original Message-
> From: Jani Taskinen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 05, 2007 2:06 PM
> To: Stanislav Malyshev
> Cc: internals@lists.php.net
> Subject: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_ini.c
>
> Sorry for the top posting De
Sorry for the top posting Derick. :)
Stas, this patch solves the problems with @ and doing
"php_admin_value error_reporting ":
http://pecl.php.net/~jani/patches/zend_alter_ini_entry.patch
I renamed zend_alter_ini_entry() to zend_alter_ini_entry_ex() and added
one more parameter to force change
See the 2nd last comment (by [EMAIL PROTECTED]):
http://bugs.php.net/bug.php?id=41561
The handling of the @ operator is the issue here. Shouldn't that be
turned on/off without touching the INI stuff anyway? (I mailed about
this earlier too, nobody bothered to reply..)
--Jani
On Fri, 2007-08-31
lead to big discussions (well, as some "random" revert might
too...)
johannes
>
> Andi
>
>
> > -Original Message-
> > From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 14, 2007 12:31 AM
> > To: Stas Malyshev
day, August 14, 2007 12:31 AM
> > To: Stas Malyshev
> > Cc: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2)
> > / zend_language_parser.y
> >
> > On 8/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> >
ot a screw you... And the patch will go in
right after 5.2.4.
Andi
> -Original Message-
> From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 14, 2007 12:31 AM
> To: Stas Malyshev
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: [ZEND-
Hannes Magnusson wrote:
On 8/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
featur
On 8/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
>
> A bug is when code doesn't do what was intended. This is not the case,
> this is the case of missing feature. While I think everybody agrees this
> feature is good to us,
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
feature is good to us, it's not the time to add it. We lived for years
without it, we c
On 8/13/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Was there something wrong with the patch or what?
>
> Yes, it was major syntax change in minor version.
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
Then this needs to be clear in the NEWS file as this is in RC1...
-Hannes
On 8/14/07, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Jani,
>
> Dmitry asked that the patch be reverted and I agreed with him. Since
> the author didn't have time (I am guessing), I've asked Stas to
> revert the patch.
Jani,
Dmitry asked that the patch be reverted and I agreed with him. Since
the author didn't have time (I am guessing), I've asked Stas to
revert the patch. The reason being that this change is too major to
commit at the very last minute in the release cycle. The code will go
back into CV
Was there something wrong with the patch or what?
Yes, it was major syntax change in minor version. These belong to
5.3/HEAD, as many others of like nature do.
Reverting without _discussing_ is not very nice..
It was discussed and I also confirmed it with the release manager (Ilia).
--
Sta
Was there something wrong with the patch or what?
Reverting without _discussing_ is not very nice..
--Jani
Stanislav Malyshev kirjoitti:
stasMon Aug 13 21:16:57 2007 UTC
Modified files: (Branch: PHP_5_2)
/ZendEngine2 zend_language_parser.y
Log:
Revert varia
Hello,
> new stage won't ever work, of course. If there's an extension which
> uses INI_STAGE_ACTIVATE and needs to support new htaccess stage, it
> can be fixed in source so check for this stage too - but I didn't see
> such extensions yet.
Well I actually know such an extension ;) It is called S
On Fri, 3 Aug 2007, Stanislav Malyshev wrote:
> > I see that this feature will be backported to older PHP 5 and even to
> > PHP 4 used by linux/bsd distributions, because it is a required security
>
> BTW: I plan to merge it in 4.4 tree, but since there's no 4.4 release planned
> soon AFAIK I wan
I see that this feature will be backported to older PHP 5 and even to
PHP 4 used by linux/bsd distributions, because it is a required security
BTW: I plan to merge it in 4.4 tree, but since there's no 4.4 release
planned soon AFAIK I want to hold for a bit to see if 5.2 testing
produces any is
However are there any plans to add a symbol or something else so that a
PHP extension can detect the support for this feature at runtime?
Hmm... I'm not sure how to do it best for the extension. I checked core
extensions and they don't use INI stages in a way that this change can
break them, a
Stanislav Malyshev schrieb:
> stas Thu Aug 2 23:57:21 2007 UTC
>
> Modified files: (Branch: PHP_5_2)
> /ZendEngine2 zend_ini.h
> Log:
> add stage for .htacces
This change is great.
However are there any plans to add a symbol or something else so that a
PHP ex
Hi Antony,
Would this change also apply to string_compare_function and
string_locale_compare_function? They currently use
zend_make_printable_zval()...
Matt
- Original Message -
From: "Antony Dovgal"
Sent: Thursday, May 17, 2007
> tony2001 Thu May 17 17:28:12 2007 UTC
>
> Modified
"Sara Golemon" <[EMAIL PROTECTED]> ??:[EMAIL PROTECTED]
> The primary reason I went this route rather than handling it in the parser
> (I did consider it), was so that a clearer error message could be given
> than "Unexpected T_STRING". If you'd rather, I'd be happy to move this
> fix over
Derick Rethans wrote:
derick Fri Nov 10 12:02:51 2006 UTC
Modified files: (Branch: PHP_5_2)
/ZendEngine2 zend_language_scanner.l
Log:
- Forward port the binary cast, which will do the same as the string cast in
PHP 5.2.
What this is supposed to do in PH
ts.php.net; Andi Gutmans; Ilia Alshanetsky
> Subject: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs:
> ZendEngine2(PHP_5_2) / zend_object_handlers.c /tests
> bug39297.phpt php-src NEWS
>
>
> Hi Dmitry!
> (moved to internal@)
>
> On 11/8/06, Dmitry Stogov <[EMAIL PROTECTED
Hi Dmitry!
(moved to internal@)
On 11/8/06, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
Hi,
Please pay attention to this patch.
It makes overloaded arrays behave in exactly the same way as overloaded
objects.
It disables indirect modification of overloaded arrays and emits notices.
It doesn't beh
On Mon, October 23, 2006 3:43 pm, Ilia Alshanetsky wrote:
>
> On 23-Oct-06, at 4:16 PM, Richard Lynch wrote:
>
>> Some ISPs will be quicker to upgrade LAMP than to let users build
>> SSH
>> tunnels.
>
> If your ISP does not give you SSH, perhaps it is time to find
> yourself another ISP.
I agree w
On 23-Oct-06, at 4:16 PM, Richard Lynch wrote:
Some ISPs will be quicker to upgrade LAMP than to let users build SSH
tunnels.
If your ISP does not give you SSH, perhaps it is time to find
yourself another ISP.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To un
On Fri, October 20, 2006 9:26 am, Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 10:24 AM, Lukas Kahwe Smith wrote:
>
>> Ilia Alshanetsky wrote:
>>
its funny that ext/mysql is supposed to stay around for BC
reasons even in PHP6, yet it has known unsolvable security issues.
>>> Such as?
>>
>
On Fri, October 20, 2006 9:35 am, Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 10:29 AM, Edin Kadribasic wrote:
>> "Known OO conventions" -> how Java people do it
>> "Its supposed to work that way" -> it works like that in Java
>> ...
>
> Java is just a single OO language out of many, http://
> en.
Gregory Beaver wrote:
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT a
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT as originally stated was
Adding more error modes is fine and dandy, but it has to be with a
good reason in mind. In my mind if we add E_DEPRECATED and mark
certain behavior as deprecated it means in a certain version, PHP6
(for example) it will go away and no longer work. Marking something
as deprecated with no int
Marcus Boerger wrote:
That said I can only repeat here what I said earlier on IRC. Lets do things
right and make the more complex OO rules as E_STRICT and create new severity
level E_DEPRECATED. E_STRICT will then only be used for 'pedantic' OO rules
while E_DEPRECATED will be used for stuff tha
Hello William,
Saturday, October 21, 2006, 1:04:44 AM, you wrote:
> Ilia Alshanetsky wrote:
>>
>> On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
>>
>>> Hello Ilia,
>>>
>>> also an ISO/shared server will never be securewhatever you do and
>>> you can
>>> make MySQL disaalow external connectio
Ilia Alshanetsky wrote:
>
> On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
>
>> Hello Ilia,
>>
>> also an ISO/shared server will never be securewhatever you do and
>> you can
>> make MySQL disaalow external connections. That basically means in those
>> scenarios you do not need any authenticat
On 10/20/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
One question I like to give to everyonedropping rules out of PHP. If you
want OO without rules, why do you use inheritance after all? Ever considered
OO might be the wrong programming paradigm for you :-)
It's not so much that "we" want OO
On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
Hello Ilia,
also an ISO/shared server will never be securewhatever you do and
you can
make MySQL disaalow external connections. That basically means in
those
scenarios you do not need any authentication at all and thus get
better
speed a
On Fri, 2006-10-20 at 23:05 +0200, Marcus Boerger wrote:
> Hello Lukas,
>
> nonsense, there was no OO in PHP 4. We only had arrays with somehow
I think you're leaning too much on a specific definition of OO that
isn't necessarily shared by the rest of the cosmos, especially the
millions of PHP4
1 - 100 of 437 matches
Mail list logo
