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 th
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 mem
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 wrote:
> On Sun, August 31, 2014 22:31, Anatol Belski wrote:
> > Hi Pierre,
> >
> >
> > On Sun,
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 nu
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
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,
On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
> On Fri, Aug 29, 2014 at 11:49 PM, Anatol Belski
> 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 string
On Aug 30, 2014 3:26 PM, "Matteo Beccati" wrote:
>
> On 30/08/2014 14:03, Chris Wright wrote:
> > On 30 August 2014 12:53, Matteo Beccati 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,
> >>
On 30/08/2014 14:03, Chris Wright wrote:
> On 30 August 2014 12:53, Matteo Beccati 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 unnecessary
On 30 August 2014 12:53, Matteo Beccati 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 memory_limit
>
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, wo
On Fri, August 29, 2014 18:34, Xinchen Hui wrote:
> On Fri, Aug 29, 2014 at 11:49 PM, Anatol Belski
> 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 string
12 matches
Mail list logo
