On Tue, 2014-08-26 at 15:09 +0200, Nikos Mavrogiannopoulos wrote: > > I think that's too much of a complexity, for such an issue. That could > also very easily break in a rewrite of internal part of libopenconnect > and would result in hard to find issues. Would it make sense to > introduce new entry functions that will simply allocate the data they > need? That would solve the issue, and will not require tracking each > and every variable used internally. But don't we already *have* entry functions in library.c for almost all cases where this is an issue? Where the original code used to just set variables such as vpninfo->host directly, we added functions like openconnect_set_hostname() to library.c. So if we just make all the functions in library.c do an appropriate strdup() + free_func() to 'internalise' the string, isn't that 99% of the job? There are a couple of cases where it *isn't* in library.c IIRC, but certainly we shouldn't need to worry about future rewrites of internal code, if we do it on the way *in*. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20140826/9579da33/attachment-0001.bin>
