2013/6/4 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
On 04/06/13 12:08, Pierre Joye wrote:
On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net** wrote:
Hey :-),
On 02/06/13 08:52, Johannes Schlüter wrote:
It would be a *gigantic* patch, but the
On Tue, Jun 4, 2013 at 6:59 AM, Michael Wallner m...@php.net wrote:
+1 for the idea
+1 for Z_STRSIZE
at least Z_STRSIZET for the reason explained earlier :)
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
+1 , that will make a big diff .
I'm here to help others to go forward.
Julien.P
On Tue, Jun 4, 2013 at 8:33 AM, Pierre Joye pierre@gmail.com wrote:
On Tue, Jun 4, 2013 at 6:59 AM, Michael Wallner m...@php.net wrote:
+1 for the idea
+1 for Z_STRSIZE
at least Z_STRSIZET for the
Hey :-),
On 02/06/13 08:52, Johannes Schlüter wrote:
It would be a *gigantic* patch, but the userland effects should be
minimal (the only changes would be supporting longer strings, and consistent 64
bit int support). The performance considerations should be minimal for
non-legacy code (as both
On Tue, 2013-06-04 at 10:41 +0200, Ivan Enderlin @ Hoa wrote:
History shows that such gigantic patches are often not finished and
done as people underestimate the size of PHP and the fact that all
etensions have to be checked which for this case means checking
each external lib for their
On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hey :-),
On 02/06/13 08:52, Johannes Schlüter wrote:
It would be a *gigantic* patch, but the userland effects should be
minimal (the only changes would be supporting longer strings, and
consistent 64
On 04/06/13 12:08, Pierre Joye wrote:
On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hey :-),
On 02/06/13 08:52, Johannes Schlüter wrote:
It would be a *gigantic* patch, but the userland effects should be
minimal (the only changes would be
On 2 June 2013 11:11, Johannes Schlüter johan...@schlueters.de wrote:
On Jun 2, 2013, at 8:34, Pierre Joye pierre@gmail.com wrote:
Obviously there's a pretty significant ABI break here. I propose a tweak
of the Z_* macros to fix that. Basically, Z_STRLEN() will cast the result
to an
On Fri, May 31, 2013 at 9:11 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Hello all,
I want to start an idea thread (or at least get a conversation going) about
cleaning up the core integer data type and string lengths. Here's my ideas:
1. Change string length in the ZVAL from int to
Andrey Hristov p...@hristov.com wrote:
what about new type IS_LONG64, new field in union and new set of macros
for this type. New extensions or rewritten extensions will use the new
macros. In 2-3 major versions, 5.8 for example, old macros will be
dropped. Enough time extensions to be ported
Anthony Ferrara ircmax...@gmail.com wrote:
1. Change string length in the ZVAL from int to size_t
- http://lxr.php.net/xref/PHP_5_5/Zend/zend.h#321
This would be good but a lot of work and an hard to track engine change ...
2. Change long in the ZVAL (lval) to a system-determined 64bit fixed
On Jun 2, 2013, at 8:34, Pierre Joye pierre@gmail.com wrote:
Obviously there's a pretty significant ABI break here. I propose a tweak
of the Z_* macros to fix that. Basically, Z_STRLEN() will cast the result
to an int. This is the same behavior as today, and will mean that existing
On Sun, Jun 2, 2013 at 11:11 AM, Johannes Schlüter
johan...@schlueters.de wrote:
On Jun 2, 2013, at 8:34, Pierre Joye pierre@gmail.com wrote:
Obviously there's a pretty significant ABI break here. I propose a tweak
of the Z_* macros to fix that. Basically, Z_STRLEN() will cast the result
Hi,
On 05/31/2013 10:03 PM, Anthony Ferrara wrote:
Derick,
In principle I think this is great thing to do. Not having a 64 bit type is
annoying. I'm a bit curious on how this is going to work with all sorts of
object wrappers that are now in place as workaround. And casting int64 to
int32
Anthony Ferrara ircmax...@gmail.com wrote:
I want to start an idea thread (or at least get a conversation going)
about
cleaning up the core integer data type and string lengths. Here's my
ideas:
1. Change string length in the ZVAL from int to size_t
-
Derick,
In principle I think this is great thing to do. Not having a 64 bit type is
annoying. I'm a bit curious on how this is going to work with all sorts of
object wrappers that are now in place as workaround. And casting int64 to
int32 needs to very well looked at as well.
As far as the
Anthony Ferrara ircmax...@gmail.com wrote:
Derick,
In principle I think this is great thing to do. Not having a 64 bit
type is
annoying. I'm a bit curious on how this is going to work with all
sorts of
object wrappers that are now in place as workaround. And casting
int64 to
int32
On Fri, May 31, 2013 at 4:21 PM, Derick Rethans der...@php.net wrote:
Anthony Ferrara ircmax...@gmail.com wrote:
Derick,
In principle I think this is great thing to do. Not having a 64 bit
type is
annoying. I'm a bit curious on how this is going to work with all
sorts of
object
18 matches
Mail list logo
