yes i thought of that and decided against it
On Fri, Feb 14, 2014 at 05:02:04PM -0600, J Raynor wrote:
> I suppose paste_replace could always handle the freeing of the memory.
> This would preserve its fire and forget nature.
>
> See the attached patch.
--
I suppose paste_replace could always handle the freeing of the memory.
This would preserve its fire and forget nature.
See the attached patch.
tmux-ml.patch
Description: Binary data
--
Android apps run on BlackBerry 10
> Why not this instead? Also fix some other similar problems.
I was hesitant to free the memory in window_copy_copy_buffer in case
the caller wasn't done with it. But since all current callers are
done with it, I guess it doesn't matter.
Your patch looks good.
--
ffers, buf, len, limit);
- } else
- paste_replace(&global_buffers, idx, buf, len);
+ } else if (paste_replace(&global_buffers, idx, buf, len) != 0)
+ free(buf);
}
void
On Fri, Feb 14, 2014 at 01:29:57AM -0600, J Raynor wrote:
>
It looks like there's a potential memory leak in
window_copy_copy_selection. This function calls
window_copy_copy_buffer, which calls paste_replace. If paste_replace
succeeds, it stores the data that was passed to it.
But if paste_replace fails, such as when an invalid buffer index is
spec
