Can you explain a bit more about when you expect this to happen? Do you
have future changes planned where you plan to pass in a non-NULL uri
parameter? Looking briefly through the later patches in this set, it
doesn't appear that any of them will pass in non-null uri parameters.
If we don't expect a non-null parameter here, perhaps we could 'enforce'
this assumption by adding something like:
g_return_val_if_fail(uri && *uri == NULL, GTK_RESPONSE_CANCEL);
On Thu, 2015-06-11 at 16:28 +0200, Lukas Venhoda wrote:
> Before writing the connection address to uri, g_free() it.
> Not freeing wouldn't cause an issue now, because uri is always NULL, but
> this could change in the future.
> ---
> Changes since v1
> - New patch
> - Free uri before using it. Just to be sure
> ---
> src/remote-viewer-connect.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/remote-viewer-connect.c b/src/remote-viewer-connect.c
> index 3927d19..6cfb7b1 100644
> --- a/src/remote-viewer-connect.c
> +++ b/src/remote-viewer-connect.c
> @@ -178,6 +178,8 @@ remote_viewer_connect_dialog(GtkWindow *main_window, gchar **uri)
> /* show and wait for response */
> gtk_widget_show_all(dialog);
>
> + g_free(*uri);
> +
> if (gtk_dialog_run(GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT) {
> *uri = g_strdup(gtk_entry_get_text(GTK_ENTRY(entry)));
> g_strstrip(*uri);
> --
> 2.4.2
>
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/virt-tools-list
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
