[libvirt] [PATCH 1/1] admin_server: use VIR_AUTOFREE() in adminClientGetInfo string
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Trivial change. Found it while reviewing a patch from Daniel yesterday. Didn't found any other instances in this file that can VIR_AUTO*. src/admin/admin_server.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/admin/admin_server.c b/src/admin/admin_server.c index 0d6091937d..dc67dd044f 100644 --- a/src/admin/admin_server.c +++ b/src/admin/admin_server.c @@ -218,7 +218,7 @@ adminClientGetInfo(virNetServerClientPtr client, int ret = -1; int maxparams = 0; bool readonly; - char *sock_addr = NULL; + VIR_AUTOFREE(char *) sock_addr = NULL; const char *attr = NULL; virTypedParameterPtr tmpparams = NULL; virIdentityPtr identity = NULL; @@ -313,7 +313,6 @@ adminClientGetInfo(virNetServerClientPtr client, if (tmpparams) virTypedParamsFree(tmpparams, *nparams); virObjectUnref(identity); - VIR_FREE(sock_addr); return ret; } -- 2.21.0
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait. Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete. Jano
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 01, 2019 at 04:25:42PM +0200, Ján Tomko wrote:
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait.
Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete.
After the feedback from my glib series, I'm doing a full conversion of this file to glib's macros anyway. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Oct 01, 2019 at 03:28:27PM +0100, Daniel P. Berrangé wrote:
On Tue, Oct 01, 2019 at 04:25:42PM +0200, Ján Tomko wrote:
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait.
Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete.
After the feedback from my glib series, I'm doing a full conversion of this file to glib's macros anyway.
Fair enough. Erik
On 10/1/19 11:25 AM, Ján Tomko wrote:
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait.
Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete.
Huh. Guess I'll stop sending those VIR_AUTO* patches all around then. I'll wait for the gnulib equivalent, if there will be any. Thanks, DHB
Jano
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Oct 01, 2019 at 11:49:25AM -0300, Daniel Henrique Barboza wrote:
On 10/1/19 11:25 AM, Ján Tomko wrote:
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait.
Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete.
Huh. Guess I'll stop sending those VIR_AUTO* patches all around then. I'll wait for the gnulib equivalent, if there will be any.
NB, glib != gnulib :-) gnulib is the POSIX portability layer we're trying to eliminate. glib is the higher level library we're trying to adopt. The new approach will be more or less identical just different naming convention. I'll get my current glib series in a working state again and push it somewhere public. That would enable you to base your work on top of the glib series, using the new glib macros, so that you're not blocked. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Oct 01, 2019 at 03:54:02PM +0100, Daniel P. Berrangé wrote:
On Tue, Oct 01, 2019 at 11:49:25AM -0300, Daniel Henrique Barboza wrote:
On 10/1/19 11:25 AM, Ján Tomko wrote:
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait.
Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete.
Huh. Guess I'll stop sending those VIR_AUTO* patches all around then. I'll wait for the gnulib equivalent, if there will be any.
NB, glib != gnulib :-)
gnulib is the POSIX portability layer we're trying to eliminate.
glib is the higher level library we're trying to adopt.
The new approach will be more or less identical just different naming convention.
So, I guess, reviewing the following would also be kinda pointless given the circumstances, wouldn't it? https://www.redhat.com/archives/libvir-list/2019-September/msg01452.html Erik
On Tue, Oct 01, 2019 at 05:01:21PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 03:54:02PM +0100, Daniel P. Berrangé wrote:
On Tue, Oct 01, 2019 at 11:49:25AM -0300, Daniel Henrique Barboza wrote:
On 10/1/19 11:25 AM, Ján Tomko wrote:
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait.
Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete.
Huh. Guess I'll stop sending those VIR_AUTO* patches all around then. I'll wait for the gnulib equivalent, if there will be any.
NB, glib != gnulib :-)
gnulib is the POSIX portability layer we're trying to eliminate.
glib is the higher level library we're trying to adopt.
The new approach will be more or less identical just different naming convention.
So, I guess, reviewing the following would also be kinda pointless given the circumstances, wouldn't it? https://www.redhat.com/archives/libvir-list/2019-September/msg01452.html
Given that we're in freeze now, we won't commit them for at least a week now. I'd hope we can get the very first glib patches merged at the start of the next cycle, which would let us go straight to the glib autofree macros. Reviewing those patches is not wasted effort though. VIR_AUTOFREE and VIR_AUTOPTR are essentially trivial renames to g_autofree / g_autoptr. The correctness of the cleanup is more important to review and that's not impacted. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 10/1/19 11:54 AM, Daniel P. Berrangé wrote:
On Tue, Oct 01, 2019 at 11:49:25AM -0300, Daniel Henrique Barboza wrote:
On 10/1/19 11:25 AM, Ján Tomko wrote:
On Tue, Oct 01, 2019 at 03:59:07PM +0200, Erik Skultety wrote:
On Tue, Oct 01, 2019 at 09:12:58AM -0300, Daniel Henrique Barboza wrote:
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- Reviewed-by: Erik Skultety <eskultet@redhat.com>
and safe for freeze
This is not a bugfix, it can wait.
Also, there is an ongoing discussion about using g_autofree once we start depending on gnulib, so I don't see a point in trying to convert code to the macro that will soon be obsolete. Huh. Guess I'll stop sending those VIR_AUTO* patches all around then. I'll wait for the gnulib equivalent, if there will be any.
NB, glib != gnulib :-)
I went with 'gnulib' following up the email from Jano! Not sure now if he was speaking about the POSIX layer or not, but I'm pinning my shame on him! :)
gnulib is the POSIX portability layer we're trying to eliminate.
glib is the higher level library we're trying to adopt.
The new approach will be more or less identical just different naming convention.
I'll get my current glib series in a working state again and push it somewhere public. That would enable you to base your work on top of the glib series, using the new glib macros, so that you're not blocked.
I appreciate that, but feel free to take your time. I'm working in other things that are unrelated to these cleanups. As soon as your patch set hits upstream (or you make the patches public) I can simply re-send all the patches changing VIR_AUTO* with the glib equivalent. Thanks, DHB
Regards, Daniel
participants (4)
-
Daniel Henrique Barboza -
Daniel P. Berrangé -
Erik Skultety -
Ján Tomko