On Wed, 9 Mar 2016 12:49:40 -0800
Andrew Morton wrote:
> On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes
> wrote:
>
> > Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> > currently works, but it is somewhat
On Wed, 9 Mar 2016 12:49:40 -0800
Andrew Morton wrote:
> On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes
> wrote:
>
> > Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> > currently works, but it is somewhat fragile, and any other overlap
> > between source and
On Wed, Mar 09 2016, Andrew Morton wrote:
> On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes
> wrote:
>
>> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
>> currently works, but it is somewhat fragile, and any other
On Wed, Mar 09 2016, Andrew Morton wrote:
> On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes
> wrote:
>
>> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
>> currently works, but it is somewhat fragile, and any other overlap
>> between source and destination buffers
On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug.
On Tue, 8 Mar 2016 21:40:47 +0100 Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug. This
> is an attempt at
On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug. This
>
On Tue, Mar 8, 2016 at 10:40 PM, Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug. This
> is an attempt at
On Tue, Mar 8, 2016 at 12:40 PM, Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug. This
>
On Tue, Mar 8, 2016 at 12:40 PM, Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug. This
> is an attempt at
On Tue, Mar 8, 2016 at 12:40 PM, Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug. This
>
On Tue, Mar 8, 2016 at 12:40 PM, Rasmus Villemoes
wrote:
> Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
> currently works, but it is somewhat fragile, and any other overlap
> between source and destination buffers would be a definite bug. This
> is an attempt at
Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
currently works, but it is somewhat fragile, and any other overlap
between source and destination buffers would be a definite bug. This
is an attempt at eliminating the relatively few occurences of this
pattern in the kernel.
I
Doing snprintf(buf, len, "%s...", buf, ...) for appending to a buffer
currently works, but it is somewhat fragile, and any other overlap
between source and destination buffers would be a definite bug. This
is an attempt at eliminating the relatively few occurences of this
pattern in the kernel.
I
14 matches
Mail list logo