From nobody Mon Feb 9 16:34:16 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=philmd@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=philmd@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1637247459; cv=none; d=zohomail.com; s=zohoarc; b=aabxJTMn5MOcfhU4ZA9Z7FSi//9Y1h3OPl9yhHyx+QEDweXEv1JAdNi/NIYYHYLgTkgpFNzGBiLN7yTYk8lhlvka88KFbMbVsoaYrK4OkzV/v01qFqODyTFFE7F6zDgY6p6skekdiZYhOJl5wBAW4QniFOWPrOTSLMOIQyNw2Gk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1637247459; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=m3us/2QX6xHvSyMB3iMuIzPGz+T3xWB4txlMwAd+l0s=; b=LUIJ/ihnAy1H+q06jBwJ57eohddLQfORiwZgmjGL9UUDGdRUtRznU9Add84WZoQPtKqTWygMjuT8G2aql6k2pdYREAxdWnP7Bu0ii8bynCvwm3H3VVG0atlpuvq/ZPIzIVEuEX59nlSsZ2aQ/+qTSKz9IGErSgZdkn0PYHnPHrM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=philmd@redhat.com; dmarc=pass header.from= (p=none dis=none) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1637247459613834.029389851954; Thu, 18 Nov 2021 06:57:39 -0800 (PST) Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-209-HKg60pfwNOCqCttYK-WFQA-1; Thu, 18 Nov 2021 09:57:36 -0500 Received: by mail-wm1-f71.google.com with SMTP id l187-20020a1c25c4000000b0030da46b76daso4435306wml.9 for ; Thu, 18 Nov 2021 06:57:36 -0800 (PST) Return-Path: Return-Path: Received: from x1w.. (62.red-83-57-168.dynamicip.rima-tde.net. [83.57.168.62]) by smtp.gmail.com with ESMTPSA id g4sm89060wro.12.2021.11.18.06.57.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 06:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637247458; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=m3us/2QX6xHvSyMB3iMuIzPGz+T3xWB4txlMwAd+l0s=; b=V7bCA94Zebaz38TtRmAaPa0V/Mj8tEIEHXQp2rFipXRBgbOKIKMMgBeL7spfrmoWQPGI/d thvjm5l4HN3hkQXUvpVQxsoIWJbupBTcQcGg2dpWghEMURxALp2GIh9LSkCsSHULoKwGhe NKaIqzEBR2jJNDvXETVHkj63IFIk1No= X-MC-Unique: HKg60pfwNOCqCttYK-WFQA-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=m3us/2QX6xHvSyMB3iMuIzPGz+T3xWB4txlMwAd+l0s=; b=KrrOSRCkrzVBbQp6dUIZGf5ze9xDY3oVPVlSqbVFRQvsZaWMjS2+mi28vZ9WBss5QN wB7YUoYkdVmdlJYNeDzFiBmdcO7g7nwMDf+Ste9nwkRda9/Ya15qUkAVY+Dp2pUyhNZz nvnJFJPrG3id5bigqVsc5MaCAl1O4e2WMQ/mOEAcpDb0Jnu8qNYAxXLcJTfOUlzuraHV yJgrMfpvuTHz9Z8EY0yKsNsxrhKRftbAJrzrijX7mwy9SidGRV4Ra/3wn3Q7Bz/s+b1i z5Xz5Q+OcRSY7MUEMUh6PmtO0D0qOQUfIyCy2W5jBZrhgpwOViBdXeli3mSdFJXDzsmN WD6w== X-Gm-Message-State: AOAM531uFw6W7St2HhJ1rh6mxG5ocsI+6KgmMEIP+S7nL9gsEXCuWBNv 6wU9XBr/YIloorEqjSCIFqt+qD6+UnFkRM+Wxw+qdRMYWnZ00amURg3kTWZxp1Geo4uXgu6pA4c ogHFMrD4rSF6UUQ== X-Received: by 2002:a05:6000:2c7:: with SMTP id o7mr32215627wry.62.1637247455261; Thu, 18 Nov 2021 06:57:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJy7Vy50/RRoqMbMb1vlB+RFIURa8dhPXf4Q0RGgcJkntxcEMZnyS4mQdt/plnR2/jpo47Cvow== X-Received: by 2002:a05:6000:2c7:: with SMTP id o7mr32215590wry.62.1637247454975; Thu, 18 Nov 2021 06:57:34 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Markus Armbruster , Peter Maydell , Darren Kenny , "Daniel P . Berrange" , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH-for-6.2? v2 4/5] docs/devel/style: Render C function names as monospaced text Date: Thu, 18 Nov 2021 15:57:15 +0100 Message-Id: <20211118145716.4116731-5-philmd@redhat.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20211118145716.4116731-1-philmd@redhat.com> References: <20211118145716.4116731-1-philmd@redhat.com> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=philmd@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1637247461136100001 Add trailing parenthesis to functions and render them as monospaced text. Signed-off-by: Philippe Mathieu-Daud=C3=A9 Reviewed-by: Alex Benn=C3=A9e --- docs/devel/style.rst | 66 +++++++++++++++++++++++--------------------- 1 file changed, 34 insertions(+), 32 deletions(-) diff --git a/docs/devel/style.rst b/docs/devel/style.rst index a7487d867e6..0397971e528 100644 --- a/docs/devel/style.rst +++ b/docs/devel/style.rst @@ -130,13 +130,13 @@ Function Naming Conventions =20 Wrapped version of standard library or GLib functions use a ``qemu_`` prefix to alert readers that they are seeing a wrapped version, for -example ``qemu_strtol`` or ``qemu_mutex_lock``. Other utility functions +example ``qemu_strtol()`` or ``qemu_mutex_lock()``. Other utility functio= ns that are widely called from across the codebase should not have any -prefix, for example ``pstrcpy`` or bit manipulation functions such as -``find_first_bit``. +prefix, for example ``pstrcpy()`` or bit manipulation functions such as +``find_first_bit()``. =20 The ``qemu_`` prefix is also used for functions that modify global -emulator state, for example ``qemu_add_vm_change_state_handler``. +emulator state, for example ``qemu_add_vm_change_state_handler()``. However, if there is an obvious subsystem-specific prefix it should be used instead. =20 @@ -385,15 +385,16 @@ avoided. Low level memory management =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 -Use of the ``malloc/free/realloc/calloc/valloc/memalign/posix_memalign`` +Use of the +``malloc()/free()/realloc()/calloc()/valloc()/memalign()/posix_memalign()`` APIs is not allowed in the QEMU codebase. Instead of these routines, use the GLib memory allocation routines -``g_malloc/g_malloc0/g_new/g_new0/g_realloc/g_free`` -or QEMU's ``qemu_memalign/qemu_blockalign/qemu_vfree`` APIs. +``g_malloc()/g_malloc0()/g_new()/g_new0()/g_realloc()/g_free()`` +or QEMU's ``qemu_memalign()/qemu_blockalign()/qemu_vfree()`` APIs. =20 -Please note that ``g_malloc`` will exit on allocation failure, so +Please note that ``g_malloc()`` will exit on allocation failure, so there is no need to test for failure (as you would have to with -``malloc``). Generally using ``g_malloc`` on start-up is fine as the +``malloc()``). Generally using ``g_malloc()`` on start-up is fine as the result of a failure to allocate memory is going to be a fatal exit anyway. There may be some start-up cases where failing is unreasonable (for example speculatively loading a large debug symbol table). @@ -401,11 +402,11 @@ anyway. There may be some start-up cases where failin= g is unreasonable Care should be taken to avoid introducing places where the guest could trigger an exit by causing a large allocation. For small allocations, of the order of 4k, a failure to allocate is likely indicative of an -overloaded host and allowing ``g_malloc`` to ``exit`` is a reasonable +overloaded host and allowing ``g_malloc()`` to ``exit()`` is a reasonable approach. However for larger allocations where we could realistically fall-back to a smaller one if need be we should use functions like -``g_try_new`` and check the result. For example this is valid approach -for a time/space trade-off like ``tlb_mmu_resize_locked`` in the +``g_try_new()`` and check the result. For example this is valid approach +for a time/space trade-off like ``tlb_mmu_resize_locked()`` in the SoftMMU TLB code. =20 If the lifetime of the allocation is within the function and there are @@ -413,7 +414,7 @@ multiple exist paths you can also improve the readabili= ty of the code by using ``g_autofree`` and related annotations. See :ref:`autofree-ref` for more details. =20 -Calling ``g_malloc`` with a zero size is valid and will return NULL. +Calling ``g_malloc()`` with a zero size is valid and will return ``NULL``. =20 Prefer ``g_new(T, n)`` instead of ``g_malloc(sizeof(T) * n)`` for the foll= owing reasons: @@ -430,14 +431,15 @@ Declarations like =20 are acceptable, though. =20 -Memory allocated by ``qemu_memalign`` or ``qemu_blockalign`` must be freed= with -``qemu_vfree``, since breaking this will cause problems on Win32. +Memory allocated by ``qemu_memalign()`` or ``qemu_blockalign()`` must be f= reed +with ``qemu_vfree()``, since breaking this will cause problems on Win32. =20 String manipulation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -Do not use the strncpy function. As mentioned in the man page, it does *n= ot* -guarantee a NULL-terminated buffer, which makes it extremely dangerous to = use. +Do not use the ``strncpy()`` function. As mentioned in the man page, it d= oes +*not* guarantee a ``NULL``-terminated buffer, which makes it extremely +dangerous to use. It also zeros trailing destination bytes out to the specified length. Ins= tead, use this similar function when possible, but note its different signature: =20 @@ -445,14 +447,14 @@ use this similar function when possible, but note its= different signature: =20 void pstrcpy(char *dest, int dest_buf_size, const char *src) =20 -Don't use strcat because it can't check for buffer overflows, but: +Don't use ``strcat()`` because it can't check for buffer overflows, but: =20 .. code-block:: c =20 char *pstrcat(char *buf, int buf_size, const char *s) =20 -The same limitation exists with sprintf and vsprintf, so use snprintf and -vsnprintf. +The same limitation exists with ``sprintf()`` and ``vsprintf()``, so use +``snprintf()`` and ``vsnprintf()``. =20 QEMU provides other useful string functions: =20 @@ -462,11 +464,11 @@ QEMU provides other useful string functions: int stristart(const char *str, const char *val, const char **ptr) int qemu_strnlen(const char *s, int max_len) =20 -There are also replacement character processing macros for isxyz and toxyz, -so instead of e.g. isalnum you should use qemu_isalnum. +There are also replacement character processing macros for ``isxyz()`` and +``toxyz()``, so instead of e.g. ``isalnum()`` you should use ``qemu_isalnu= m()``. =20 -Because of the memory management rules, you must use g_strdup/g_strndup -instead of plain strdup/strndup. +Because of the memory management rules, you must use ``g_strdup()/g_strndu= p()`` +instead of plain ``strdup()/strndup()``. =20 Printf-style functions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -525,10 +527,10 @@ automatic cleanup: =20 Most notably: =20 -* g_autofree - will invoke g_free() on the variable going out of scope +* ``g_autofree`` - will invoke ``g_free()`` on the variable going out of s= cope =20 -* g_autoptr - for structs / objects, will invoke the cleanup func created - by a previous use of G_DEFINE_AUTOPTR_CLEANUP_FUNC. This is +* ``g_autoptr`` - for structs / objects, will invoke the cleanup func crea= ted + by a previous use of ``G_DEFINE_AUTOPTR_CLEANUP_FUNC``. This is supported for most GLib data types and GObjects =20 For example, instead of @@ -552,7 +554,7 @@ For example, instead of return ret; } =20 -Using g_autofree/g_autoptr enables the code to be written as: +Using ``g_autofree/g_autoptr`` enables the code to be written as: =20 .. code-block:: c =20 @@ -570,13 +572,13 @@ Using g_autofree/g_autoptr enables the code to be wri= tten as: While this generally results in simpler, less leak-prone code, there are still some caveats to beware of =20 -* Variables declared with g_auto* MUST always be initialized, +* Variables declared with ``g_auto*`` MUST always be initialized, otherwise the cleanup function will use uninitialized stack memory =20 -* If a variable declared with g_auto* holds a value which must +* If a variable declared with ``g_auto*`` holds a value which must live beyond the life of the function, that value must be saved - and the original variable NULL'd out. This can be simpler using - g_steal_pointer + and the original variable ``NULL``'d out. This can be simpler using + ``g_steal_pointer``. =20 =20 .. code-block:: c --=20 2.31.1