On Mon, September 1, 2014 19:07, Anatol Belski wrote:
Hi Dmitry,
On Mon, September 1, 2014 16:17, Dmitry Stogov wrote:
Hi Anatol,
what do you mean? heap allocated structure? I think, it's not a good
option :(
I didn't have time to think about this yet.
I thought about creating an
On Sun, August 31, 2014 22:31, Anatol Belski wrote:
Hi Pierre,
On Sun, August 31, 2014 14:12, Pierre Joye wrote:
Hi Anatol,
Thanks!
For what I see it should have no impact, either mem usage or perf but
when such offset is used, in 64bit.
However some numbers are better, could you
Hi Anatol,
what do you mean? heap allocated structure?
I think, it's not a good option :(
I didn't have time to think about this yet.
Thanks. Dmitry.
On Mon, Sep 1, 2014 at 5:37 PM, Anatol Belski anatol@belski.net wrote:
On Sun, August 31, 2014 22:31, Anatol Belski wrote:
Hi Pierre,
Hi Dmitry,
On Mon, September 1, 2014 16:17, Dmitry Stogov wrote:
Hi Anatol,
what do you mean? heap allocated structure? I think, it's not a good
option :(
I didn't have time to think about this yet.
I thought about creating an extended zend_string struct with an appended
offset member.
On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
On Fri, Aug 29, 2014 at 11:49 PM, Anatol Belski anatol@belski.net
wrote:
Hi,
while refining the big string support, it turned out that we've an
issue. The syntax like $s[42] = 'x'; is currently inconsistend, because
we have uint32 for
Hi Anatol,
Thanks!
For what I see it should have no impact, either mem usage or perf but when
such offset is used, in 64bit.
However some numbers are better, could you provide some using exclusively
this syntax and using common apps pls? Only to be sure.
Cheers,
Pierre
On Aug 31, 2014 1:57 PM,
Hi Pierre,
On Sun, August 31, 2014 14:12, Pierre Joye wrote:
Hi Anatol,
Thanks!
For what I see it should have no impact, either mem usage or perf but
when such offset is used, in 64bit.
However some numbers are better, could you provide some using exclusively
this syntax and using
On 29/08/2014 23:58, Anatol Belski wrote:
On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
if a string is bigger than 2^32... I think there must be a bug :)
Only for this case you mean, or generally? As we safe with memory_limit
anyway.
Even though size_t allows huge strings, would it
On 30 August 2014 12:53, Matteo Beccati p...@beccati.com wrote:
On 29/08/2014 23:58, Anatol Belski wrote:
On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
if a string is bigger than 2^32... I think there must be a bug :)
Only for this case you mean, or generally? As we safe with
On 30/08/2014 14:03, Chris Wright wrote:
On 30 August 2014 12:53, Matteo Beccati p...@beccati.com wrote:
Even though size_t allows huge strings, would it be so bad to throw an
error when one tries to create a string longer than 2^32 bytes,
regardless of memory_limit?
This would be an
On Aug 30, 2014 3:26 PM, Matteo Beccati p...@beccati.com wrote:
On 30/08/2014 14:03, Chris Wright wrote:
On 30 August 2014 12:53, Matteo Beccati p...@beccati.com wrote:
Even though size_t allows huge strings, would it be so bad to throw
an
error when one tries to create a string longer
On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
On Fri, Aug 29, 2014 at 11:49 PM, Anatol Belski anatol@belski.net
wrote:
Hi,
while refining the big string support, it turned out that we've an
issue. The syntax like $s[42] = 'x'; is currently inconsistend, because
we have uint32 for
12 matches
Mail list logo
