From nobody Sun Feb 8 15:46:14 2026
Delivered-To: importer@patchew.org
Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28
as permitted sender) client-ip=209.132.183.28;
envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com;
Authentication-Results: mx.zohomail.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=pass(p=none dis=none) header.from=redhat.com
ARC-Seal: i=1; a=rsa-sha256; t=1571235970; cv=none;
d=zoho.com; s=zohoarc;
b=VFIEG/BMv+qnp3wkkNMyvr5yFpb4RJUBOQIPZwrcruslQNbzY4D85V1h/+eEi7A4Y4JYkJXjaMCK6lf1ER0wtxr6LHn6oLmCQovyCZGiOaQXQ4yqMRIhC859YfQX4hNqK6M0ixamYtT7Y64kkUYyCbV+M+RAWoL/8xF5KcB9hmk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc;
t=1571235970;
h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To;
bh=K0F5xkdi5SeHCQta2Q4K4RPQqdrD+YKUhRK4iRmicDU=;
b=g4WKM0z+MoFTVMZPVAlxKtv4EOct1rF0U7z1zySRM2jRPDL+iDV51ANi/EbG4SvDVkUPzH73zyhel0YxSyz1A8drAn/PxFTeY/n3UFWXtlnQx+BQntyiiE/ljloeZ3teUODNwfb6ha8d+u3OotLOnH78g1TTo0+WIyHM7B7BECw=
ARC-Authentication-Results: i=1; mx.zoho.com;
spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as
permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com;
dmarc=pass header.from= for functions/names
X-BeenThere: libvir-list@redhat.com
X-Mailman-Version: 2.1.12
Precedence: junk
List-Id: Development discussions about the libvirt library & tools
element more in the GLib section.
Signed-off-by: J=C3=A1n Tomko
VIR_ALLOC, VIR_REALLOC,
+ VIR_RESIZE_N, VIR_EXPAND_N,
+ VIR_SHRINK_N, VIR_FREE,
+ VIR_APPEND_ELEMENT, VIR_INSERT_ELEMENT,
+ VIR_DELETE_ELEMENTg_new0/g_renew/
+ g_free in most cases. There should rarely be a need
+ to use g_malloc/g_realloc.
Instead of using plain C arrays, it is preferrable to use
- one of the GLib types, GArray, GPtrArray or GByteArray. These
+ one of the GLib types, GArray, GPtrArray
+ or GByteArray. These
all use a struct to track the array memory and size together
and efficiently resize. NEVER MIX use of the
classic libvirt memory allocation APIs and GLib APIs within
a single method. Keep the style consistent, converting existing
code to GLib style in a separate, prior commit.VIR_STRDUP, VIR_STRNDUPg_strdup and g_strndup=
code>.virAsprintf, virVasprintfg_strdup_printf / g_strdup_vpri=
nt should be used
+ instead. Don't use g_vasprintf unless having the stri=
ng length
returned is unavoidable.virStrerrorg_strerror() function should be used inste=
ad,
which has a simpler calling convention as an added benefit.VIR_AUTOPTR, VIR_AUTOCLEAN, VIR_=
AUTOFREEg_autoptr, g_auto and
+ g_autofree must be used
instead in all new code. In existing code, the GLib macros must
never be mixed with libvirt macros within a method, nor should
- they be mixed with VIR_FREE. If introducing GLib macros to an
+ they be mixed with VIR_FREE. If introducing GLib macr=
os to an
existing method, any use of libvirt macros must be converted
in an independent commit.
VIR_DEFINE_AUTOPTR_FUNC, VIR_DEFINE_AUTOCLEAN=
_FUNCG_DEFINE_AUTOPTR_CLEANUP_FUNC and
+ G_DEFINE_AUTO_CLEANUP_CLEAR_FUNC must be used in all
new code. Existing code should be converted to the
new macros where relevant. It is permissible to use
- g_autoptr, g_auto on an object whose cleanup function
+ g_autoptr, g_auto on an object whose cle=
anup function
is declared with the libvirt macros and vice-verca.
VIR_AUTOUNREFg_autoptr and G_DEFINE_AUTOPT=
R_CLEANUP_FUNC
should be used to manage autoclean of virObject classes.
This matches usage with GObject classes.