On 06/29/2018 06:56 AM, Rainer Orth wrote:
Hi Martin,
While looking into opportunities to detect strnlen/strlen coding
mistakes (pr86199) I noticed a bug in the strnlen implementation
I committed earlier today that lets a strnlen() result be saved
and used in subsequent calls to strlen() with t
Hi Martin,
> While looking into opportunities to detect strnlen/strlen coding
> mistakes (pr86199) I noticed a bug in the strnlen implementation
> I committed earlier today that lets a strnlen() result be saved
> and used in subsequent calls to strlen() with the same argument.
> The attached patch
On 06/22/2018 04:00 PM, Jeff Law wrote:
On 06/18/2018 01:15 PM, Martin Sebor wrote:
While looking into opportunities to detect strnlen/strlen coding
mistakes (pr86199) I noticed a bug in the strnlen implementation
I committed earlier today that lets a strnlen() result be saved
and used in subseq
On 06/18/2018 01:15 PM, Martin Sebor wrote:
> While looking into opportunities to detect strnlen/strlen coding
> mistakes (pr86199) I noticed a bug in the strnlen implementation
> I committed earlier today that lets a strnlen() result be saved
> and used in subsequent calls to strlen() with the sam
While looking into opportunities to detect strnlen/strlen coding
mistakes (pr86199) I noticed a bug in the strnlen implementation
I committed earlier today that lets a strnlen() result be saved
and used in subsequent calls to strlen() with the same argument.
The attached patch changes the handle_b
