On Tue, 2014-08-26 at 15:23 +0200, Nikos Mavrogiannopoulos wrote: > On Tue, Aug 26, 2014 at 3:13 PM, David Woodhouse <dwmw2 at infradead.org> 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. > > I meant to add openconnect_set_hostname_const() which will simply > strdup() its input and avoid messing with the caller's memory at all. If we were going to do that, I'd probably be inclined just to break the API completely and make them *all* behave like that. It's a much cleaner API. I could actually be seriously tempted. I can fix up the GNOME and KDE side, the Java code is easily fixed, and that leaves your code and Shimo. I suspect Fabian won't be *too* inconvenienced by having to change... and it's "only" a memory leak if he forgets, anyway. > So you suggest adding an openconnect_set_user_free(), which will be > used by openconnect_set_hostname() and friends? I don't like it much, > but it requires less changes and it would work too. That's what I was thinking, yes. It's probably the same number of changes as if you do it in your client, but just in a slightly more enumerable and future-proof fashion. But now I'm half-way to talking myself into just bumping the soname and having *all* functions take 'const char *' :) -- 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/f284acee/attachment.bin>
