Hi Stats,
2011/12/4 Stas Malyshev smalys...@sugarcrm.com:
If user really want to set session ID, they can explicitly disable
use_strict_mode.
For almost all application, setting static ID is bad code. There are
some applications that exploit adoptive session, but they can live
with new code
Hi Stats,
I updated the patch to address discussion.
https://gist.github.com/1379668
2011/12/4 Stas Malyshev smalys...@sugarcrm.com:
Hi!
My main concern with this change is that it is binary incompatible with
existing session implementation, which means it would be hard to get it into
5.3
Hi Stats,
2011/12/4 Stas Malyshev smalys...@sugarcrm.com:
If we care about binary API compatibility, how about make
PS_MOD_SID2/PS_MOD_FUNCS_SID2
macros? Then we can forget about ABI.
I'm sorry, I don't understand how any macros would help anything. Adding
stuff to the structure would
2011/12/4 Yasuo Ohgaki yohg...@ohgaki.net:
Hi Stats,
2011/12/4 Stas Malyshev smalys...@sugarcrm.com:
If we care about binary API compatibility, how about make
PS_MOD_SID2/PS_MOD_FUNCS_SID2
macros? Then we can forget about ABI.
I'm sorry, I don't understand how any macros would help
Hi!
Since it is just adding new separate structure to session module, but
PHP itself checks API version number. So users cannot use the same
binary module anyway. I should have said API, not ABI.
Now it should compile with msession which uses PHP_MOD_SID/PS_MOD_FUNCS_SID.
That's the problem.
Hi!
For example, it is easy to find cases with google code search, that
users are setting ID while they really should do is
session_regenerate_id(). These kind of mistakes would be better to be
prevented under strict mode, IMHO.
I'm not sure how that would help in this case - so the set
Hi Stats,
2011/12/4 Stas Malyshev smalys...@sugarcrm.com:
Hi!
For example, it is easy to find cases with google code search, that
users are setting ID while they really should do is
session_regenerate_id(). These kind of mistakes would be better to be
prevented under strict mode, IMHO.
This is ready for review now.
https://bugs.php.net/patch-display.php?bug=60362patch=fix_disabling_bad_string_offsetsrevision=1323002696
This resolves the worst behavior changes introduced by the dereferencing
of strings fix.
https://bugs.php.net/bug.php?id=60362
All tests (in Zend/tests)
hi!
same here.
Thanks for this patch!
On Sun, Dec 4, 2011 at 2:28 PM, Ilia Alshanetsky i...@prohost.org wrote:
Seems like a good change +1.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi,
2011/12/4 Alan Knowles a...@akbkhome.com:
This is ready for review now.
https://bugs.php.net/patch-display.php?bug=60362patch=fix_disabling_bad_string_offsetsrevision=1323002696
This resolves the worst behavior changes introduced by the dereferencing of
strings fix.
On Sat, Dec 3, 2011 at 5:08 PM, Alan Knowles a...@akbkhome.com wrote:
I've had a look at making string offsets of strings a bit saner.
At present with the fix for array dereferencing : ?search=hello and a
test like isset($_GET['search']['name']) results in true, which is has
potential
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
In the end it is a relatively simple patch. The new syntax effectively creates
internal functions on the object and the system looks for those functions and
calls them at the appropriate time.
Example:
class
+1.
thanks.
On Sun, Dec 4, 2011 at 10:05 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Sat, Dec 3, 2011 at 5:08 PM, Alan Knowles a...@akbkhome.com wrote:
I've had a look at making string offsets of strings a bit saner.
At present with the fix for array dereferencing : ?search=hello and a
Hi,
why not creating a more function like syntax for this feature. In my
opinion it looks more cleaner particularly when using more than one line
in a setter or getter. The other thing is that you can use type hints
with this syntax.
As example:
class Foo {
private $bar;
public
hi,
Please attach the patch (and any future version) to the RFC and to
https://bugs.php.net/bug.php?id=49526, so it won't be lost if your
sever goes down.
Thanks!
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi,
2011/12/4 Clint M Priest cpri...@zerocue.com:
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
In the end it is a relatively simple patch. The new syntax effectively
creates internal functions on the object and the system looks for those
functions
2011/12/4 Felipe Pena felipe...@gmail.com:
Hi,
2011/12/4 Clint M Priest cpri...@zerocue.com:
Updated patch w/o white-space:
http://www.clintpriest.com/patches/accessors_v1.patch
In the end it is a relatively simple patch. The new syntax effectively
creates internal functions on the
Hi,
On Sun, Dec 4, 2011 at 15:25, Laruence larue...@php.net wrote:
+1.
thanks.
On Sun, Dec 4, 2011 at 10:05 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Sat, Dec 3, 2011 at 5:08 PM, Alan Knowles a...@akbkhome.com wrote:
I've had a look at making string offsets of strings a bit saner.
On Mon, Dec 5, 2011 at 12:39 AM, Etienne Kneuss col...@php.net wrote:
Hi,
On Sun, Dec 4, 2011 at 15:25, Laruence larue...@php.net wrote:
+1.
thanks.
On Sun, Dec 4, 2011 at 10:05 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Sat, Dec 3, 2011 at 5:08 PM, Alan Knowles a...@akbkhome.com
On Sun, 2011-12-04 at 00:08 +0800, Alan Knowles wrote:
This patch is a start.
https://bugs.php.net/patch-display.php?bug_id=60362patch=first_effort_to_fix_thisrevision=latest
It's been quite a while since I hacked on the engine, so the patch only
works reasonably well.. (see the FIXME on
While it might seem like a good idea to put something like this into
APC it really just creates more problems than it is worth. I belive it
was removed for that very reason; because it was making it difficult
to distinguish opcode cache errors from optimizer errors.
There was an attempt to move
Ignore this patch for now, I'll get these issues addressed and I also want to
improve the performance a bit.
Felipe, I'll check out those failing tests, I found the CODING_STANDARDS doc
and will read it.
With regards to performance, I'm creating the __getHours string on each
invocation. I
Hi:
I have submit a new patch based on the origin patch, which only
trigger notice when string offset cast occurred.
thanks
On Sun, Dec 4, 2011 at 10:25 PM, Laruence larue...@php.net wrote:
+1.
thanks.
On Sun, Dec 4, 2011 at 10:05 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Sat, Dec
I see your point about optimization being time consuming and the
penalty being greater if you're not using a bytecode cache. But that's
a reason to make it optional, not a reason to couple it with a
specific bytecode cache so it can't be used with others.
As for optimization not accomplishing all
Just an idea: it would interesting to have the optimisation running
concurrently, to update the opcode cache with an optimised version, taking
all the time it is needed for strong optimisations. If the optimisation is
not ready for the first request it will be later when the optimisation is
A few answers...
$s = string; isset($s['offset']) returns false
This is pretty critical, as it's the only way to detect this situation,
and ensure that array tests do not return positive results for strings.
It also catches an obvious, but previously hidden and probably serious
bugs in the
2011/12/4 Johannes Schlüter johan...@schlueters.de
On Sun, 2011-12-04 at 00:08 +0800, Alan Knowles wrote:
This patch is a start.
https://bugs.php.net/patch-display.php?bug_id=60362patch=first_effort_to_fix_thisrevision=latest
It's been quite a while since I hacked on the engine, so the
Hi Stats,
2011/12/4 Stas Malyshev smalys...@sugarcrm.com:
Hi!
If we care about binary API compatibility, how about make
PS_MOD_SID2/PS_MOD_FUNCS_SID2
macros? Then we can forget about ABI.
I'm sorry, I don't understand how any macros would help anything. Adding
stuff to the structure
Hi:
I think we can only trigger notice, then act the same behavior as
before. include isset.
this would introduce the fewest bc breaks,
what do you think?
thanks
On Mon, Dec 5, 2011 at 7:25 AM, Alan Knowles a...@akbkhome.com wrote:
A few answers...
$s = string; isset($s['offset'])
On Monday, December 05, 2011 11:21 AM, Laruence wrote:
Hi:
I think we can only trigger notice, then act the same behavior as
before. include isset.
this would introduce the fewest bc breaks,
I think the isset behavior should be fixed (as the BC will be broken
anyway with deferenced
30 matches
Mail list logo
