From nobody Sun Feb 8 18:57:21 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=1637075610; cv=none; d=zohomail.com; s=zohoarc; b=BYMaZ8+N8QR2GktOgaMnzNWycr/qCiQf+I3yfDrR1cfbFSSRoe5X/QCKS8mJFJmPqMQ8iQruf8OcSzKuy4GdSd6uhVKsNP6q3ma0fayUWfTHzvZSMd8FdkYF1hSK/vbEDWOpfsEB4B8IZVBHjD4bgkI+veBwwmyMwkabiHGSsqI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1637075610; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=I9uHr78Bd1hAdWgud7dJDANsSM/mJBoe5Km+LIqe2vI=; b=CkIE+LGRmxOIB6hpjwv8iWsWVkQj3yHoFjTvYfopZXUvyllEGANu9s41/0XbCp3aMMy++hZo+b6NVx5GxHUKTLo++/TEh7MLlX1TRNmk0ejhcUkQm/sHFLmF9EOStAEQ+PxaGuWbYjewO3Q0U+f1zT/On6HNu2kEiqXCUYuCtCI= 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 1637075610632471.23222287564636; Tue, 16 Nov 2021 07:13:30 -0800 (PST) Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-297-9jbaa0W5PDuAZEYKylcenQ-1; Tue, 16 Nov 2021 10:13:26 -0500 Received: by mail-wr1-f69.google.com with SMTP id a2-20020a5d4d42000000b0017b3bcf41b9so4568324wru.23 for ; Tue, 16 Nov 2021 07:13:25 -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 ay21sm2876646wmb.7.2021.11.16.07.13.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 07:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637075609; 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=I9uHr78Bd1hAdWgud7dJDANsSM/mJBoe5Km+LIqe2vI=; b=OMifRM3zsQ+FhKCDhCVaW6o+AElqhLA82j1w5to4RLkbnUQQuM1Be5XZTgx8UpzaNhvr2+ Nf4eHla926WILiJwNucRO7AeodbK+pN4mjinh5/DEQANhijWd+hZm2v9GN+xp1puIPM+mI GSdbJfzo7/4uYfB2EIlbfq82MlPKv48= X-MC-Unique: 9jbaa0W5PDuAZEYKylcenQ-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=I9uHr78Bd1hAdWgud7dJDANsSM/mJBoe5Km+LIqe2vI=; b=zT5ebn+CRZsZePOahzR84MT8ie9SOuZnSgImIDrq+ZsR+EOt79XGnBkbQSCCY3G7BR KyPYu86TMOoQjx8AW4JCroiY0I9APe6htHd1CwC78jXhYmyABffDLNts6CyeSNVe+1NM R3C6YPmMfzdMZ++I6kpPoJWgkLxTDf4WrILPmVh3mHfsN14bZWi4MnK0y8/6NMfnt77F mTOEvGAY7FjKSPBdPG9h3/a/1dw+DNxiTc17BnOMQ1jYD11E9CY8QMvHeMU5fxxQtL9T yN1zSTZdGOpXSE9FG0pumKaJa31cD1vluBD7VtOlpQDIA1Gk06RuLLs5zBhVf3fxxplK di7A== X-Gm-Message-State: AOAM530Ldl9VCJ80URr2i2As6tyYHf0ZP8kO2fg/0u79SmzsRjyy/s8Q oXskYUYaZZq8z5Ha4+mH3iDHVvSKjoM900bobaH1HWaRiR3j1UEi0lirKTIBDPRehduh/4ltXNT wE/x+p0qjOjuJIQ== X-Received: by 2002:a1c:7714:: with SMTP id t20mr60375342wmi.139.1637075604678; Tue, 16 Nov 2021 07:13:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQYAhFyLdU4iFhA7VfEwTgn75yNRIJwDNqnRdl+aOTf1vwgs7GNXm8/DtcNIOrpkLojnQBIg== X-Received: by 2002:a1c:7714:: with SMTP id t20mr60375296wmi.139.1637075604394; Tue, 16 Nov 2021 07:13:24 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Peter Maydell , "Daniel P . Berrange" , Markus Armbruster , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH-for-6.2? 1/3] docs/devel/style: Improve GLib functions rST rendering Date: Tue, 16 Nov 2021 16:13:15 +0100 Message-Id: <20211116151317.2691125-2-philmd@redhat.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20211116151317.2691125-1-philmd@redhat.com> References: <20211116151317.2691125-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: 1637075647315100001 Signed-off-by: Philippe Mathieu-Daud=C3=A9 --- docs/devel/style.rst | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/docs/devel/style.rst b/docs/devel/style.rst index 260e3263fa0..415a6b9d700 100644 --- a/docs/devel/style.rst +++ b/docs/devel/style.rst @@ -413,13 +413,14 @@ multiple exist paths you can also improve the readabi= lity 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: =20 -* It catches multiplication overflowing size_t; -* It returns T ``*`` instead of void ``*``, letting compiler catch more ty= pe errors. +* It catches multiplication overflowing ``size_t``; +* It returns ``T *`` instead of ``void *``, letting compiler catch more ty= pe + errors. =20 Declarations like =20 @@ -444,14 +445,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 @@ -464,8 +465,8 @@ QEMU provides other useful string functions: There are also replacement character processing macros for isxyz and toxyz, so instead of e.g. isalnum you should use qemu_isalnum. =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_strndup`` +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 @@ -524,10 +525,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 @@ -551,7 +552,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 @@ -569,13 +570,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 + ``g_steal_pointer`` =20 =20 .. code-block:: c --=20 2.31.1 From nobody Sun Feb 8 18:57:21 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=1637075613; cv=none; d=zohomail.com; s=zohoarc; b=UlJUjmo2KBa6N83nabM8Ck2Bok27u1d0ePC0CprwJHOGQhWooGaDOaPE7RJcUKj1xnRj4M1Mmp8RErgQcY3GMaU3jDIS2TMs3VAHV3hxqjtRq2mQVvov1QKskrAxM9kgVagCuuS+NmYUB7c6UUgmctsGufTyU7Btcn9sKVLc3OQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1637075613; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=Ms3B9QbG5Lq6X9ovVT6jCZ1RA1SZmRfiYx9TmX6F1t4=; b=ThP3BPwhQ6Ha5keRXRSh3A2nLZEYIp9ihORdN1ab4csjSJ5g/sh9EoJqMH9eNaxSUnRHTfqV6xRQPhxzIPxK29TcS4mWGZIBCFbVMW5kXVx7dhc30HRepeeE/PpmDa4BDJjWoWN0p1xX37d0AFnLfeOpsPupyOPmPvLa9BAJfOA= 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 163707561339282.9226876649243; Tue, 16 Nov 2021 07:13:33 -0800 (PST) Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-273-BLT4LMTGNCevk96j17TE5w-1; Tue, 16 Nov 2021 10:13:31 -0500 Received: by mail-wm1-f70.google.com with SMTP id g80-20020a1c2053000000b003331a764709so1349789wmg.2 for ; Tue, 16 Nov 2021 07:13:30 -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 o4sm3141465wmq.31.2021.11.16.07.13.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 07:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637075612; 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=Ms3B9QbG5Lq6X9ovVT6jCZ1RA1SZmRfiYx9TmX6F1t4=; b=DfW75/pTxLByrQTPWqYY2ablkMMCh/7OfghoXh7dR3yzEcCVuo5eimdfk6fiN9uVPVuYI5 Oh1hSPghJB4TG+Bv3/F6wPIHi74xgzEu8BZM5rAX1swnDF41CaohyQY5CYoYe6Z7iG8KOR j8+QEZzUZ1AZoJWio9uCad9m1TUzY/Y= X-MC-Unique: BLT4LMTGNCevk96j17TE5w-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=Ms3B9QbG5Lq6X9ovVT6jCZ1RA1SZmRfiYx9TmX6F1t4=; b=Mt3t4og7dpSSGr8tWn+91bMz/N1gCbKP5CqngL6Vf00jCBfQKXsmc51RglVLpH0b2T 3RZ/bcO6x2MOB192BajuEWXaV04BwxQSJLsZCCcXfrdGqel54gRM5tKg/ZVc6TgUOU/i 3kb578nhg9ppTqxNzbK6WRPd+tbG7SdqZSiX1TLE1LYkcp9T36nw0LGlaFGvvqdEmV6v gOYzPym4QU70WnFiUYlZCCjy3JgpEHpsk6ByXurfl1t7q5LGqveqpjxcmdU6Cuav0jC+ 0ss9az3iD2gNEfW5p5KjghA5zjn+wEPzLkZq8OJBjW0atEAl7txW+AE5HTUBjDPLzhia nRXA== X-Gm-Message-State: AOAM531y2i8qvbCxHBLu4NYZXxLn0clojGMpbZ6b42Cxj9Chc12X2GMI B3FkuuEuMqg7CrjbIgnI07WBeCC/JzR+PbzWuqrxUw7Hutqz4bKfa109TZipJMX1OG5YI8KJn+m yFG2WSTan3KP97g== X-Received: by 2002:a5d:46cb:: with SMTP id g11mr10255439wrs.26.1637075609360; Tue, 16 Nov 2021 07:13:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJyKrIz4ZXrYywbmjqVM+jHNv8Gv2kN8EykBs2fpvd6a/Pt52hzN1viz2/PIyiFpw2ui9yGJBg== X-Received: by 2002:a5d:46cb:: with SMTP id g11mr10255376wrs.26.1637075609047; Tue, 16 Nov 2021 07:13:29 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Peter Maydell , "Daniel P . Berrange" , Markus Armbruster , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH-for-6.2? 2/3] docs/devel/style: Improve Error** functions rST rendering Date: Tue, 16 Nov 2021 16:13:16 +0100 Message-Id: <20211116151317.2691125-3-philmd@redhat.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20211116151317.2691125-1-philmd@redhat.com> References: <20211116151317.2691125-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: 1637075649670100001 Signed-off-by: Philippe Mathieu-Daud=C3=A9 --- docs/devel/style.rst | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/devel/style.rst b/docs/devel/style.rst index 415a6b9d700..21f0f213193 100644 --- a/docs/devel/style.rst +++ b/docs/devel/style.rst @@ -602,16 +602,16 @@ Error handling and reporting Reporting errors to the human user ---------------------------------- =20 -Do not use printf(), fprintf() or monitor_printf(). Instead, use -error_report() or error_vreport() from error-report.h. This ensures the -error is reported in the right place (current monitor or stderr), and in -a uniform format. +Do not use ``printf()``, ``fprintf()`` or ``monitor_printf()``. Instead, = use +``error_report()`` or ``error_vreport()`` from error-report.h. This ensur= es +the error is reported in the right place (current monitor or ``stderr``), = and +in a uniform format. =20 -Use error_printf() & friends to print additional information. +Use ``error_printf()`` & friends to print additional information. =20 -error_report() prints the current location. In certain common cases +``error_report()`` prints the current location. In certain common cases like command line parsing, the current location is tracked -automatically. To manipulate it manually, use the loc_``*``() from +automatically. To manipulate it manually, use the ``loc_*()`` from error-report.h. =20 Propagating errors @@ -621,7 +621,7 @@ An error can't always be reported to the user right whe= re it's detected, but often needs to be propagated up the call chain to a place that can handle it. This can be done in various ways. =20 -The most flexible one is Error objects. See error.h for usage +The most flexible one is ``Error`` objects. See error.h for usage information. =20 Use the simplest suitable method to communicate success / failure to @@ -631,10 +631,10 @@ error, non-negative / -errno, non-null / null, or Err= or objects. Example: when a function returns a non-null pointer on success, and it can fail only in one way (as far as the caller is concerned), returning null on failure is just fine, and certainly simpler and a lot easier on -the eyes than propagating an Error object through an Error ``*````*`` para= meter. +the eyes than propagating an Error object through an ``Error **`` paramete= r. =20 Example: when a function's callers need to report details on failure -only the function really knows, use Error ``*````*``, and set suitable err= ors. +only the function really knows, use ``Error **``, and set suitable errors. =20 Do not report an error to the user when you're also returning an error for somebody else to handle. Leave the reporting to the place that @@ -643,17 +643,17 @@ consumes the error returned. Handling errors --------------- =20 -Calling exit() is fine when handling configuration errors during +Calling ``exit()`` is fine when handling configuration errors during startup. It's problematic during normal operation. In particular, -monitor commands should never exit(). +monitor commands should never ``exit()``. =20 -Do not call exit() or abort() to handle an error that can be triggered +Do not call ``exit()`` or ``abort()`` to handle an error that can be trigg= ered by the guest (e.g., some unimplemented corner case in guest code translation or device emulation). Guests should not be able to terminate QEMU. =20 -Note that &error_fatal is just another way to exit(1), and &error_abort -is just another way to abort(). +Note that ``&error_fatal`` is just another way to ``exit(1)``, and +``&error_abort`` is just another way to ``abort()``. =20 =20 trace-events style --=20 2.31.1 From nobody Sun Feb 8 18:57:21 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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.133.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=1637075619; cv=none; d=zohomail.com; s=zohoarc; b=EiHo5zDkkj3VmUksJT+689QODp7/EHN74pPS69KIdVLVYxcx6R/kivan8YWYGCfVB5yCllvIMFMrvyifeQ8xLJWADPehF1qJH3dZWwrqWZu98JiVXRbFGxum7gtufE+6Ex1fb2aWpGWfrhHsogtP13XkHALTSPviGfY0fmkx1DE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1637075619; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=vzyuU0brrhhvWPox+fPOqudlzzVJ1atjfhhAL4J13rY=; b=lg75Q3M7wIfKzfIAUe/oPMwCGiPtWvRv+z35e41Z8+EAu440Bde88WL3Y6sCwGeHozPVs8rM9cAZaqbyxnTWOQU6NXGhli2UIjuCZARTWtorxmIb5mIMVqWDOIAhrGIv1FHKeyEPl9EgZ1zOhwwaFb89pvE1JziJBGOwaUaT2UU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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.133.124]) by mx.zohomail.com with SMTPS id 16370756190428.730135271066501; Tue, 16 Nov 2021 07:13:39 -0800 (PST) Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-144-aWEwwcH2Mg-tLLAX7dwStA-1; Tue, 16 Nov 2021 10:13:36 -0500 Received: by mail-wr1-f70.google.com with SMTP id p17-20020adff211000000b0017b902a7701so4569591wro.19 for ; Tue, 16 Nov 2021 07:13: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 y12sm17483212wrn.73.2021.11.16.07.13.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Nov 2021 07:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637075617; 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=vzyuU0brrhhvWPox+fPOqudlzzVJ1atjfhhAL4J13rY=; b=UuGJ99TeIWUw+/1Gl/sVvWz+j7WV78UPL9e+nEkiJ+kFV1vNrTON2ArpgqJrvOQw6A2SNb GWCbEBocGbz222wCfN9letliYfBPorfnZznkNYVihXGtOudJeCJkjFVUPoBFLgx7eBxp7j xyx1Sbx9DEsAeWtIC1yrrTYB+AdBCbo= X-MC-Unique: aWEwwcH2Mg-tLLAX7dwStA-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=vzyuU0brrhhvWPox+fPOqudlzzVJ1atjfhhAL4J13rY=; b=ojI7RlaQ2gXjq1oYRi24L7tm7QwckDIWRg6WwaiIE+Iuuek202rhrA7d6Wi/6QOVN5 PHO5HHEt36FY8YsD6VNQorNT9XZ2M8l4Hq+dMDLKQrQF/2r6N3ayn4P/7riF0sShFq8k 1ypXmJkOVasWvUAZYx5dhcZ9HfYr4XUSSU6kGOxI62GKYqaIOg3RMFwfGUrHQsCRyi7l 3qrV9j6VsC2ayFDzMSrxhDcgDZBVphnpbrWf5hPoxbMcAcgUGzoqnK4Bu/iSQDe8HjSo IdMcbAUsuB5ukEGm0srq5cADAPiqbSUJ5QsCh11biE5toiGlF5i9WlZTC56PEgSsYvkb NTqQ== X-Gm-Message-State: AOAM533dThPY6b5NuCCrKw2+YO/HlffEzs5Q9WwEkxNMr5l4XxarTskx u3AfY5qKIWe6o66HP5MdixdADXrBeR4qnHCVFErPixbdh0pnUmiliRvcRLajmGLQiLvzQD8I69l WKHK91xxSEYvCow== X-Received: by 2002:a5d:66cb:: with SMTP id k11mr10006194wrw.253.1637075615016; Tue, 16 Nov 2021 07:13:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJwjtZ6DBQ6n07vT9BTp5kNy1gB0VdY5NYd+l3B80Slda9jokh/Oepy5lccikqFHruKHvkSIiQ== X-Received: by 2002:a5d:66cb:: with SMTP id k11mr10006133wrw.253.1637075614661; Tue, 16 Nov 2021 07:13:34 -0800 (PST) From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Cc: Peter Maydell , "Daniel P . Berrange" , Markus Armbruster , =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= Subject: [PATCH-for-6.2? 3/3] docs/devel/style: Improve types/qualifiers rST rendering Date: Tue, 16 Nov 2021 16:13:17 +0100 Message-Id: <20211116151317.2691125-4-philmd@redhat.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20211116151317.2691125-1-philmd@redhat.com> References: <20211116151317.2691125-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: 1637075653217100001 Signed-off-by: Philippe Mathieu-Daud=C3=A9 --- docs/devel/style.rst | 111 ++++++++++++++++++++++--------------------- 1 file changed, 56 insertions(+), 55 deletions(-) diff --git a/docs/devel/style.rst b/docs/devel/style.rst index 21f0f213193..f9f063ed8cb 100644 --- a/docs/devel/style.rst +++ b/docs/devel/style.rst @@ -111,7 +111,7 @@ Variables are lower_case_with_underscores; easy to type= and read. Structured type names are in CamelCase; harder to type but standing out. Enum type names and function type names should also be in CamelCase. Scalar type names are lower_case_with_underscores_ending_with_a_t, like the POSIX -uint64_t and family. Note that this last convention contradicts POSIX +``uint64_t`` and family. Note that this last convention contradicts POSIX and is therefore likely to be changed. =20 Variable Naming Conventions @@ -195,9 +195,9 @@ blocks) are generally not allowed; declarations should = be at the beginning of blocks. =20 Every now and then, an exception is made for declarations inside a -#ifdef or #ifndef block: if the code looks nicer, such declarations can +``#ifdef`` or ``#ifndef`` block: if the code looks nicer, such declaration= s can be placed at the top of the block even if there are statements above. -On the other hand, however, it's often best to move that #ifdef/#ifndef +On the other hand, however, it's often best to move that ``#ifdef/#ifndef`` block to a separate function altogether. =20 Conditional statements @@ -220,13 +220,13 @@ even when the constant is on the right. Comment style =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -We use traditional C-style /``*`` ``*``/ comments and avoid // comments. +We use traditional C-style ``/*`` ``*/`` comments and avoid ``//`` comment= s. =20 -Rationale: The // form is valid in C99, so this is purely a matter of +Rationale: The ``//`` form is valid in C99, so this is purely a matter of consistency of style. The checkpatch script will warn you about this. =20 Multiline comment blocks should have a row of stars on the left, -and the initial /``*`` and terminating ``*``/ both on their own lines: +and the initial ``/*`` and terminating ``*/`` both on their own lines: =20 .. code-block:: c =20 @@ -290,57 +290,57 @@ a few useful guidelines here. Scalars ------- =20 -If you're using "int" or "long", odds are good that there's a better type. -If a variable is counting something, it should be declared with an -unsigned type. +If you're using '``int``' or '``long``', odds are good that there's a bett= er +type. If a variable is counting something, it should be declared with an +*unsigned* type. =20 -If it's host memory-size related, size_t should be a good choice (use -ssize_t only if required). Guest RAM memory offsets must use ram_addr_t, +If it's host memory-size related, ``size_t`` should be a good choice (use +``ssize_t`` only if required). Guest RAM memory offsets must use ``ram_add= r_t``, but only for RAM, it may not cover whole guest address space. =20 -If it's file-size related, use off_t. -If it's file-offset related (i.e., signed), use off_t. -If it's just counting small numbers use "unsigned int"; +If it's file-size related, use ``off_t``. +If it's file-offset related (i.e., signed), use ``off_t``. +If it's just counting small numbers use '``unsigned int``'; (on all but oddball embedded systems, you can assume that that type is at least four bytes wide). =20 In the event that you require a specific width, use a standard type -like int32_t, uint32_t, uint64_t, etc. The specific types are +like ``int32_t``, ``uint32_t``, ``uint64_t``, etc. The specific types are mandatory for VMState fields. =20 -Don't use Linux kernel internal types like u32, __u32 or __le32. +Don't use Linux kernel internal types like ``u32``, ``__u32`` or ``__le32`= `. =20 -Use hwaddr for guest physical addresses except pcibus_t -for PCI addresses. In addition, ram_addr_t is a QEMU internal address +Use ``hwaddr`` for guest physical addresses except ``pcibus_t`` +for PCI addresses. In addition, ``ram_addr_t`` is a QEMU internal address space that maps guest RAM physical addresses into an intermediate address space that can map to host virtual address spaces. Generally -speaking, the size of guest memory can always fit into ram_addr_t but +speaking, the size of guest memory can always fit into ``ram_addr_t`` but it would not be correct to store an actual guest physical address in a -ram_addr_t. +``ram_addr_t``. =20 For CPU virtual addresses there are several possible types. -vaddr is the best type to use to hold a CPU virtual address in +``vaddr`` is the best type to use to hold a CPU virtual address in target-independent code. It is guaranteed to be large enough to hold a virtual address for any target, and it does not change size from target to target. It is always unsigned. -target_ulong is a type the size of a virtual address on the CPU; this means +``target_ulong`` is a type the size of a virtual address on the CPU; this = means it may be 32 or 64 bits depending on which target is being built. It should therefore be used only in target-specific code, and in some performance-critical built-per-target core code such as the TLB code. -There is also a signed version, target_long. -abi_ulong is for the ``*``-user targets, and represents a type the size of -'void ``*``' in that target's ABI. (This may not be the same as the size o= f a +There is also a signed version, ``target_long``. +``abi_ulong`` is for the ``*-user`` targets, and represents a type the siz= e of +'``void *``' in that target's ABI. (This may not be the same as the size o= f a full CPU virtual address in the case of target ABIs which use 32 bit point= ers -on 64 bit CPUs, like sparc32plus.) Definitions of structures that must mat= ch +on 64 bit CPUs, like *sparc32plus*.) Definitions of structures that must m= atch the target's ABI must use this type for anything that on the target is def= ined -to be an 'unsigned long' or a pointer type. -There is also a signed version, abi_long. +to be an '``unsigned long``' or a pointer type. +There is also a signed version, ``abi_long``. =20 Of course, take all of the above with a grain of salt. If you're about -to use some system interface that requires a type like size_t, pid_t or -off_t, use matching types for any corresponding variables. +to use some system interface that requires a type like ``size_t``, ``pid_t= `` or +``off_t``, use matching types for any corresponding variables. =20 -Also, if you try to use e.g., "unsigned int" as a type, and that +Also, if you try to use e.g., '``unsigned int``' as a type, and that conflicts with the signedness of a related variable, sometimes it's best just to use the *wrong* type, if "pulling the thread" and fixing all related variables would be too invasive. @@ -352,9 +352,9 @@ casts, then reconsider or ask for help. Pointers -------- =20 -Ensure that all of your pointers are "const-correct". +Ensure that all of your pointers are "``const``-correct". Unless a pointer is used to modify the pointed-to storage, -give it the "const" attribute. That way, the reader knows +give it the '``const``' attribute. That way, the reader knows up-front that this is a read-only pointer. Perhaps more importantly, if we're diligent about this, when you see a non-const pointer, you're guaranteed that it is used to modify the storage @@ -363,7 +363,7 @@ it points to, or it is aliased to another pointer that = is. Typedefs -------- =20 -Typedefs are used to eliminate the redundant 'struct' keyword, since type +Typedefs are used to eliminate the redundant '``struct``' keyword, since t= ype names have a different style than other identifiers ("CamelCase" versus "snake_case"). Each named struct type should have a CamelCase name and a corresponding typedef. @@ -462,8 +462,8 @@ 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_isalnum``. =20 Because of the memory management rules, you must use ``g_strdup/g_strndup`` instead of plain ``strdup/strndup``. @@ -472,10 +472,10 @@ 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 =20 Whenever you add a new printf-style function, i.e., one with a format -string argument and following "..." in its prototype, be sure to use +string argument and following '``...``' in its prototype, be sure to use gcc's printf attribute directive in the prototype. =20 -This makes it so gcc's -Wformat and -Wformat-security options can do +This makes it so gcc's ``-Wformat`` and ``-Wformat-security`` options can = do their jobs and cross-check format strings with the number and types of arguments. =20 @@ -503,7 +503,7 @@ painful. These are: the sign bit (ie it is an arithmetic shift, not a logical shift) =20 In addition, QEMU assumes that the compiler does not use the latitude -given in C99 and C11 to treat aspects of signed '<<' as undefined, as +given in C99 and C11 to treat aspects of signed '``<<``' as undefined, as documented in the GNU Compiler Collection manual starting at version 4.0. =20 .. _autofree-ref: @@ -659,10 +659,10 @@ Note that ``&error_fatal`` is just another way to ``e= xit(1)``, and trace-events style =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -0x prefix ---------- +``0x`` prefix +------------- =20 -In trace-events files, use a '0x' prefix to specify hex numbers, as in: +In trace-events files, use a '``0x``' prefix to specify hex numbers, as in: =20 .. code-block:: c =20 @@ -676,27 +676,28 @@ PCI bus id): =20 another_trace(int cssid, int ssid, int dev_num) "bus id: %x.%x.%04x" =20 -However, you can use '0x' for such groups if you want. Anyway, be sure that +However, you can use '``0x``' for such groups if you want. Anyway, be sure= that it is obvious that numbers are in hex, ex.: =20 .. code-block:: c =20 data_dump(uint8_t c1, uint8_t c2, uint8_t c3) "bytes (in hex): %02x %0= 2x %02x" =20 -Rationale: hex numbers are hard to read in logs when there is no 0x prefix, -especially when (occasionally) the representation doesn't contain any lett= ers -and especially in one line with other decimal numbers. Number groups are a= llowed -to not use '0x' because for some things notations like %x.%x.%x are used n= ot -only in Qemu. Also dumping raw data bytes with '0x' is less readable. +Rationale: hex numbers are hard to read in logs when there is no '``0x``' +prefix, especially when (occasionally) the representation doesn't contain = any +letters and especially in one line with other decimal numbers. Number grou= ps +are allowed to not use '``0x``' because for some things notations like +'``%x.%x.%x``' are used not only in QEMU. Also dumping raw data bytes with +'``0x``' is less readable. =20 -'#' printf flag ---------------- +'``#``' printf flag +------------------- =20 -Do not use printf flag '#', like '%#x'. +Do not use printf flag '``#``', like '``%#x``'. =20 -Rationale: there are two ways to add a '0x' prefix to printed number: '0x%= ...' -and '%#...'. For consistency the only one way should be used. Arguments for -'0x%' are: +Rationale: there are two ways to add a '``0x``' prefix to printed number: +'``0x%...``' and '``%#...``'. For consistency the only one way should be u= sed. +Arguments for '``0x%``' are: =20 * it is more popular -* '%#' omits the 0x for the value 0 which makes output inconsistent +* '``%#``' omits the ``0x`` for the value ``0`` which makes output inconsi= stent --=20 2.31.1