Hi Tiran,
Am 11.12.2011 21:57, schrieb Tiran Kaskas:
> Looking into the function alloc_buf_gc() in file buffer.c, it returns a
> struct buffer, which seems to me is allocated on the stack, which is
> causing an issue, I believe, since the function calling alloc_buf_gc()
> will work on a buffer whi
On 12/11/2011 02:37:02 PM, Gert Doering wrote:
> Of course nobody wants to reimplement all library functions (except
> djb, maybe, but we do not want to go there), but given some functions
> with sufficiently vague or messy calling semantics, having a better
> defined local implementation can i
Looking into the function alloc_buf_gc() in file buffer.c, it returns a struct
buffer, which seems to me is allocated on the stack, which is causing an issue,
I believe, since the function calling alloc_buf_gc() will work on a buffer
which becomes garbage.
Please confirm I am not missing someth
Hi,
On Fri, Dec 09, 2011 at 08:19:31PM +0200, Alon Bar-Lev wrote:
> In my opinion, in order to avoid confusion there can be two options:
>
> 1. Use library functions as much as possible, providing the minimum
> common ground
> in compatibility layer if missing. This ensure applying fixes and
> fu
Hi,
cutting off most of this long mail, and pointing to a few - IMHO -
important aspects.
On Fri, Dec 09, 2011 at 09:50:02PM +0100, David Sommerseth wrote:
[..]
> >>> So I'd propose to keep openvpn_basename() - it's simple and short
> >>> enough, and has well-defined semantics that can be relied
