On 10/02/2016 11:51 PM, Amos Jeffries wrote:
> On 3/10/2016 1:03 p.m., Alex Rousskov wrote:
>> On 10/02/2016 03:25 PM, Kinkie wrote:
>>> On Fri, Sep 30, 2016 at 6:03 PM, Alex Rousskov
Overall, I know of three primary ways to implement c_str():
1. Always 0-terminate SBuf-used
On 3/10/2016 1:03 p.m., Alex Rousskov wrote:
> On 10/02/2016 03:25 PM, Kinkie wrote:
>> On Fri, Sep 30, 2016 at 6:03 PM, Alex Rousskov
>> wrote:
>>> On 09/29/2016 09:19 PM, Amos Jeffries wrote:
On 30/09/2016 5:03 a.m., Alex Rousskov wrote:
> Should we
On 10/02/2016 03:25 PM, Kinkie wrote:
> On Fri, Sep 30, 2016 at 6:03 PM, Alex Rousskov
> wrote:
>> On 09/29/2016 09:19 PM, Amos Jeffries wrote:
>>> On 30/09/2016 5:03 a.m., Alex Rousskov wrote:
Should we remove the increment to make concurrent c_str() calls
On Fri, Sep 30, 2016 at 6:03 PM, Alex Rousskov
wrote:
> On 09/29/2016 09:19 PM, Amos Jeffries wrote:
>> On 30/09/2016 5:03 a.m., Alex Rousskov wrote:
>>> Should we remove the increment to make concurrent c_str() calls safe?
>
>> The reason it exists remember is
On 09/29/2016 09:19 PM, Amos Jeffries wrote:
> On 30/09/2016 5:03 a.m., Alex Rousskov wrote:
>> Should we remove the increment to make concurrent c_str() calls safe?
> The reason it exists remember is to prevent other SBuf sharing that
> storage MemBuf from thinking they can append to the storage
On 30/09/2016 5:03 a.m., Alex Rousskov wrote:
> Hello,
>
> The current trunk code contains at least two serious bugs caused by
> SBuf::c_str() misuse. Both known bugs looks similar:
>
>> storeCreateEntry(storeUri.c_str(), storeUri.c_str(), ...);
>
> and
>
>> storeCreateEntry(uri.c_str(),
Hello,
The current trunk code contains at least two serious bugs caused by
SBuf::c_str() misuse. Both known bugs looks similar:
> storeCreateEntry(storeUri.c_str(), storeUri.c_str(), ...);
and
> storeCreateEntry(uri.c_str(), uri.c_str(), ...);
Both use cases violate safe c_str() use