From patchwork Thu Nov 18 14:57:12 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= X-Patchwork-Id: 1556708 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=NUFiWepu; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Hw2x72mm5z9sPf for ; Fri, 19 Nov 2021 01:58:35 +1100 (AEDT) Received: from localhost ([::1]:51632 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mnirw-0004Ue-JG for incoming@patchwork.ozlabs.org; Thu, 18 Nov 2021 09:58:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mniqu-0004QI-Kb for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:28963) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mniqr-00082u-MR for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637247444; 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=/sBYOa2h22qqCaXNmWikjc24bg3qqY1FNjgkcCrf8RE=; b=NUFiWepu0ezIJ19IQDTRqZrbKHkxss8960y4FJ3zxBgC8R6pcuHOPeKPordsRzlq34/I1z XLNWqv9EV3GBbnMBguevGiPsknorKxUjQRwspwohWLaR2nU5+kX5H0zBju7rxMHjaMr1oD kPo6IBq5MVYM3WOSovjDDIkvUDYRkMs= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-553-M4gPu_87NwiLULdXNlhKrg-1; Thu, 18 Nov 2021 09:57:24 -0500 X-MC-Unique: M4gPu_87NwiLULdXNlhKrg-1 Received: by mail-wr1-f71.google.com with SMTP id y10-20020adffa4a000000b0017eea6cb05dso1146293wrr.6 for ; Thu, 18 Nov 2021 06:57:23 -0800 (PST) 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=/sBYOa2h22qqCaXNmWikjc24bg3qqY1FNjgkcCrf8RE=; b=yU2by/OfeqyQbFp7XPGUhkhWhPdd8U/r5PUzZ0FIsHFoFkHLqId/C2qQPGl5MTsKz8 PfVrH0sLvFS92amJGSt33O2mL+Ofe4qNxK9LQw8sQSTiemlvTw/dPfPV+arB+Va4uQag UHIbiOe7ohPDdgQe4cPhYr8EITiXXmR1IOu/yFn1PT7bD8TWr8Eg/YorzKIKDKQYdJF+ TA07R3VgdcN8rBX5gV/av1OM8cMxcQxCeF7Qut6ivbgHYhaM83qsfimyiwHh1Vhm3fA3 /mxNHc6N9ty7doA40wKC76MNHaQHG9rejOxuqL6QIxZhVOUT1eOIA2fFTLy8qIoLKR64 9mCg== X-Gm-Message-State: AOAM5327cLdKD5dcXMj5yrOdtOjSd33opkZmNmL1B75r2VPVy+PA4GUE xkrpFMA5qlQQo7/96/nKV21Ji9AK5tm9Swj8ArTJBjMkoiEMES7j5APJ8Xu4AF+o+vwuQqzcVge 8FVplApwi2mIy7Y6uJp7ofOuUK9Ab2YRpmxIJdplquy33hArFe3+Z3fUrMvt56VLF X-Received: by 2002:a05:6000:181:: with SMTP id p1mr31961485wrx.292.1637247442411; Thu, 18 Nov 2021 06:57:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJwbaWYbx+81L3A2uMQ7E+xXjuqJi+VdIcV7V1z1J9YNySN3KDUkR1Gyg1jOwtaldysuX7gw+Q== X-Received: by 2002:a05:6000:181:: with SMTP id p1mr31961425wrx.292.1637247442040; Thu, 18 Nov 2021 06:57:22 -0800 (PST) Received: from x1w.. (62.red-83-57-168.dynamicip.rima-tde.net. [83.57.168.62]) by smtp.gmail.com with ESMTPSA id r8sm118850wrz.43.2021.11.18.06.57.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 06:57:21 -0800 (PST) From: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH-for-6.2? v2 1/5] docs/devel/style: Render C types as monospaced text Date: Thu, 18 Nov 2021 15:57:12 +0100 Message-Id: <20211118145716.4116731-2-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 Received-SPF: pass client-ip=216.205.24.124; envelope-from=philmd@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?utf-8?q?Philippe_Mathieu-Dau?= =?utf-8?q?d=C3=A9?= , "Daniel P . Berrange" , Markus Armbruster , Darren Kenny Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée --- docs/devel/style.rst | 59 ++++++++++++++++++++++---------------------- 1 file changed, 30 insertions(+), 29 deletions(-) diff --git a/docs/devel/style.rst b/docs/devel/style.rst index e00af62e763..3e519dc6ade 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. Variable Naming Conventions @@ -290,57 +290,57 @@ a few useful guidelines here. Scalars ------- -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 better +type. If a variable is counting something, it should be declared with an +*unsigned* type. -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_addr_t``, but only for RAM, it may not cover whole guest address space. -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). 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. -Don't use Linux kernel internal types like u32, __u32 or __le32. +Don't use Linux kernel internal types like ``u32``, ``__u32`` or ``__le32``. -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``. 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 of a +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 of a full CPU virtual address in the case of target ABIs which use 32 bit pointers -on 64 bit CPUs, like sparc32plus.) Definitions of structures that must match +on 64 bit CPUs, like *sparc32plus*.) Definitions of structures that must match the target's ABI must use this type for anything that on the target is defined -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``. 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. -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. @@ -363,7 +363,7 @@ it points to, or it is aliased to another pointer that is. Typedefs -------- -Typedefs are used to eliminate the redundant 'struct' keyword, since type +Typedefs are used to eliminate the redundant '``struct``' keyword, since type 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. @@ -418,8 +418,9 @@ Calling ``g_malloc`` with a zero size is valid and will return NULL. Prefer ``g_new(T, n)`` instead of ``g_malloc(sizeof(T) * n)`` for the following reasons: -* It catches multiplication overflowing size_t; -* It returns T ``*`` instead of void ``*``, letting compiler catch more type errors. +* It catches multiplication overflowing ``size_t``; +* It returns ``T *`` instead of ``void *``, letting compiler catch more type + errors. Declarations like From patchwork Thu Nov 18 14:57:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= X-Patchwork-Id: 1556711 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=NXtK2NZT; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Hw3111ddlz9ssD for ; Fri, 19 Nov 2021 02:01:57 +1100 (AEDT) Received: from localhost ([::1]:59308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mnivD-0001IN-2G for incoming@patchwork.ozlabs.org; Thu, 18 Nov 2021 10:01:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mniqy-0004WT-1d for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:32 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20634) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mniqv-00083U-Mj for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637247449; 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=/HpEathA5riapQobuv/wwQs6HF4NNRoprJj+KElllXM=; b=NXtK2NZT46UgUns73DoJL1BMYbW75suhGssaUTgTrNNq+EtE/3jyl9qxHj+hPWkpSCTyi6 Q13c7qcytLVyokkpbN7uQYf3v3CrgRcbSRw2A2q2wT4A8QzK8etkXoKBidZH2AM+a3lx8s 4wYxsSM97cBs3e8xULFdiooOgaiDWGM= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-501-gkPI-Mh9MeO2EJ_pVr0IzA-1; Thu, 18 Nov 2021 09:57:28 -0500 X-MC-Unique: gkPI-Mh9MeO2EJ_pVr0IzA-1 Received: by mail-wr1-f72.google.com with SMTP id o4-20020adfca04000000b0018f07ad171aso1133628wrh.20 for ; Thu, 18 Nov 2021 06:57:28 -0800 (PST) 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=/HpEathA5riapQobuv/wwQs6HF4NNRoprJj+KElllXM=; b=T9v9mNq9Eu1FuCLmrDkL/3rUvl2yhiiuYqJuJix/jdMtTn2uQaoigsQ6BkLi7Bn65c PRSKOSjoEnI//yYiXRIwu8iYGIH49uNL7E8scdnoEvrwLhTHht4JA1pr5RtMOPM5gGBA KxIjaojyVmbB4jTggJSdTbvdL6ff1wReqnK3a8QrvQCg2KVifqpTx55iWmCrS2H9nG+S mrz/nkz+ndKFxcCSYiRgsj+p04cyZNhlTlxep0cRPrephMBT2GcXct3m8bUWIKVFSNnM PbCFdIweYbTaG8iq9X+jnIoKUeD9q2MZ3PmDWhCXADWv9szmigWtKjh3ljeWj2GlLzsJ Na8Q== X-Gm-Message-State: AOAM531VJE/2Lyz4BbUwl61zquCkYoXnfzk7fOOKz9WrPbnn6W9IBlYo enl+g7c3K4wceq5ttYnlW2AZgilY6lQrrOSKb6O/t3t4vgn0yjdHz+uUy+9fxkeLV33pl162uLa bER7byeLstrRXkUkWabTnfXWAbZQg1AyKbz1n3RkDOm00y26cvv3xsCCnCpFLIhm3 X-Received: by 2002:adf:dd0a:: with SMTP id a10mr32197037wrm.60.1637247446720; Thu, 18 Nov 2021 06:57:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJy9540F1z7RYJ5+NhbiHpVspcg/n+EsQJDIPIvg6LAIdPON8lY1Ry++DNhW9b/FKJUIJYSG8Q== X-Received: by 2002:adf:dd0a:: with SMTP id a10mr32196978wrm.60.1637247446390; Thu, 18 Nov 2021 06:57:26 -0800 (PST) Received: from x1w.. (62.red-83-57-168.dynamicip.rima-tde.net. [83.57.168.62]) by smtp.gmail.com with ESMTPSA id 38sm119011wrc.1.2021.11.18.06.57.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 06:57:26 -0800 (PST) From: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH-for-6.2? v2 2/5] docs/devel/style: Improve Error** functions rST rendering Date: Thu, 18 Nov 2021 15:57:13 +0100 Message-Id: <20211118145716.4116731-3-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 Received-SPF: pass client-ip=216.205.24.124; envelope-from=philmd@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?utf-8?q?Philippe_Mathieu-Dau?= =?utf-8?q?d=C3=A9?= , "Daniel P . Berrange" , Markus Armbruster , Darren Kenny Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée --- 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 3e519dc6ade..1a23021bc3e 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 ---------------------------------- -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 ensures +the error is reported in the right place (current monitor or ``stderr``), and +in a uniform format. -Use error_printf() & friends to print additional information. +Use ``error_printf()`` & friends to print additional information. -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. Propagating errors @@ -621,7 +621,7 @@ An error can't always be reported to the user right where 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. -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. Use the simplest suitable method to communicate success / failure to @@ -631,10 +631,10 @@ error, non-negative / -errno, non-null / null, or Error 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 ``*````*`` parameter. +the eyes than propagating an Error object through an ``Error **`` parameter. Example: when a function's callers need to report details on failure -only the function really knows, use Error ``*````*``, and set suitable errors. +only the function really knows, use ``Error **``, and set suitable errors. 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 --------------- -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()``. -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 triggered by the guest (e.g., some unimplemented corner case in guest code translation or device emulation). Guests should not be able to terminate QEMU. -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()``. trace-events style From patchwork Thu Nov 18 14:57:14 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= X-Patchwork-Id: 1556713 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=CL1xe1rt; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Hw32X4cVMz9sPf for ; Fri, 19 Nov 2021 02:03:16 +1100 (AEDT) Received: from localhost ([::1]:36362 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mniwU-0004ws-GF for incoming@patchwork.ozlabs.org; Thu, 18 Nov 2021 10:03:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52556) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnir3-0004eg-M0 for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:39 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:55101) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnir1-00083p-BR for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637247453; 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=6DiSDv3PdVbuzBwVbsPBRsE403y5aRBjXVqhRXtzZwI=; b=CL1xe1rtwsDeCo3UIbKDgVZWXjX1VhB1cCeZIbdouJr2BUq6XguXaMGeZU8U4U+qpgAZ3r dkqi2Jd19GjfgG8QkOyUB8fqrczHamlbHiAh1vkRfGoZMl0AuaX+kZLYyLBRL+CMAvQQNv AsdYnr6oNNd/luux5gMxaSV55yXQhBs= 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-581-zLNRpDigMSG0OHDAfjKciA-1; Thu, 18 Nov 2021 09:57:32 -0500 X-MC-Unique: zLNRpDigMSG0OHDAfjKciA-1 Received: by mail-wm1-f71.google.com with SMTP id 187-20020a1c02c4000000b003335872db8dso2206063wmc.2 for ; Thu, 18 Nov 2021 06:57:32 -0800 (PST) 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=6DiSDv3PdVbuzBwVbsPBRsE403y5aRBjXVqhRXtzZwI=; b=a51JBxYvD9snmRFd/UPyCWCmnayvy4K43lOlO7/v5Mv27UvZzZ36LZ1ZjGWvDuQqRM hb+UxIG6yUS7s6/6ObtmKYj9cxXPqA3s4HI3m1JOPwFdiTe5tDe8KOLUteGvBFvya8QA 9yue+Aw55kgZ9uE+/NWxSUxhiq+NCXNdGAlieLpo4Hqf+mm6bqit3KS2eZdN9iNo+Vc4 mK9Y9hol9rm8lapMJL033itWXyI7gc/M08mq3+xCsY2bPpxdBxV8IBYVTNmG8QdJHj7C 2qQ3AH3z4+l7Vbilmr7uRVOuKVROIrOFUXfD47jbJZZrhr+BPyUrjvZbnbK3hxxwl4Ta x1/g== X-Gm-Message-State: AOAM5336RwENUk24TLNb11btc/eEVzKMWW4aXnjxtrG2t+qEr0HjTq/K BT54AXKRuy4FkqghCxE3WDgoNVsM69JnaL1fOXrfw/2iY323njUIp3niylFnJ53bjuPyK2EBMtJ TyOv+KnzoGo4ii//fubSuJjr4Fg9CdBYyQPZcLRZCu2Rru1YkGUXUKkALmVaMKsT1 X-Received: by 2002:a1c:a715:: with SMTP id q21mr10926062wme.23.1637247450957; Thu, 18 Nov 2021 06:57:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJwFehAPCodWGX22DYzque1Ork/YjeZDpJjpMHY+Bq8h0Rt0bxqYzveTzZqKA3MfHMEK+z02Mg== X-Received: by 2002:a1c:a715:: with SMTP id q21mr10926028wme.23.1637247450721; Thu, 18 Nov 2021 06:57:30 -0800 (PST) Received: from x1w.. (62.red-83-57-168.dynamicip.rima-tde.net. [83.57.168.62]) by smtp.gmail.com with ESMTPSA id b10sm81077wrt.36.2021.11.18.06.57.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 06:57:30 -0800 (PST) From: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH-for-6.2? v2 3/5] docs/devel/style: Improve string format rST rendering Date: Thu, 18 Nov 2021 15:57:14 +0100 Message-Id: <20211118145716.4116731-4-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 Received-SPF: pass client-ip=216.205.24.124; envelope-from=philmd@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?utf-8?q?Philippe_Mathieu-Dau?= =?utf-8?q?d=C3=A9?= , "Daniel P . Berrange" , Markus Armbruster , Darren Kenny Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée --- docs/devel/style.rst | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/docs/devel/style.rst b/docs/devel/style.rst index 1a23021bc3e..a7487d867e6 100644 --- a/docs/devel/style.rst +++ b/docs/devel/style.rst @@ -471,11 +471,11 @@ instead of plain strdup/strndup. Printf-style functions ====================== -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 -gcc's printf attribute directive in the prototype. +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 +gcc's ``printf()`` attribute directive in the prototype. -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. @@ -659,10 +659,10 @@ Note that ``&error_fatal`` is just another way to ``exit(1)``, and trace-events style ================== -0x prefix ---------- +``0x`` prefix +------------- -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: .. code-block:: c @@ -676,27 +676,28 @@ PCI bus id): another_trace(int cssid, int ssid, int dev_num) "bus id: %x.%x.%04x" -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.: .. code-block:: c data_dump(uint8_t c1, uint8_t c2, uint8_t c3) "bytes (in hex): %02x %02x %02x" -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 groups 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. +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 groups +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. -'#' printf flag ---------------- +'``#``' printf flag +------------------- -Do not use printf flag '#', like '%#x'. +Do not use printf flag '``#``', like '``%#x``'. -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 used. +Arguments for '``0x%``' are: * 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 inconsistent From patchwork Thu Nov 18 14:57:15 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= X-Patchwork-Id: 1556709 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=V7bCA94Z; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Hw2xQ5v9Gz9sPf for ; Fri, 19 Nov 2021 01:58:49 +1100 (AEDT) Received: from localhost ([::1]:52154 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mnis9-0004tU-8a for incoming@patchwork.ozlabs.org; Thu, 18 Nov 2021 09:58:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnir7-0004nr-O2 for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:41 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:27107) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnir4-00084F-Tn for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:41 -0500 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= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-53-Mm9eSH4wNjyBk6Yq5sLAzg-1; Thu, 18 Nov 2021 09:57:37 -0500 X-MC-Unique: Mm9eSH4wNjyBk6Yq5sLAzg-1 Received: by mail-wm1-f70.google.com with SMTP id n16-20020a05600c3b9000b003331973fdbbso3264194wms.0 for ; Thu, 18 Nov 2021 06:57:36 -0800 (PST) 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=SfpVHv5Wi6E4phmwSZ5ONo5mCMn1mFSE8+vTtTKMALU8bS44DtpPxaqd/1gHec2NIC 9SbPMXdJMpYEMo75LlrOLw06F3y/Ym278L2DfeSaI+MVsXbKwsxQNAROgf+g4K6LW+Tj LzazHqJO/Lc3udPlUT+VieeU/M9eyksO7NKRPzdX+O1JLFDoo9Gie+Yr8ZSNBpENBIJ1 iCk59FEDbmWS+m6Od7c2f3Bmh8AXQZoHOY3dkQF0aqr2PbswwG/iwT+poU1esF/SO1bA GLdeHRF36DQXhIhvzBt4dXzl6t/6Bv9KF+z32ZYEy1QpVv+y1eX0SCzJemG8HKLuu+n5 mfHw== X-Gm-Message-State: AOAM530+V7oD9FVkSXqyBBLfNGiY6pk6ATn2vaEXKbd8lnvkPsBbaEEY pREcOkFN6jhPTTjcvUb5+NI5lhVcPPVdoHlZiU+hsHeN1N0Og/pMV2qdIw0g/ECUaOF9Faf/UC7 CokXRFUjh0U16rcbVOsjx1rE07+IuuPZl2qknB4kBq273VpXsAB6HaJVNOFV56fx7 X-Received: by 2002:a05:6000:2c7:: with SMTP id o7mr32215637wry.62.1637247455329; 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) 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) From: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org 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 Received-SPF: pass client-ip=170.10.129.124; envelope-from=philmd@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?utf-8?q?Philippe_Mathieu-Dau?= =?utf-8?q?d=C3=A9?= , "Daniel P . Berrange" , Markus Armbruster , Darren Kenny Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Add trailing parenthesis to functions and render them as monospaced text. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée --- 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 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 functions 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()``. 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. @@ -385,15 +385,16 @@ avoided. Low level memory management =========================== -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. -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 failing 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. 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 readability of the code by using ``g_autofree`` and related annotations. See :ref:`autofree-ref` for more details. -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``. Prefer ``g_new(T, n)`` instead of ``g_malloc(sizeof(T) * n)`` for the following reasons: @@ -430,14 +431,15 @@ Declarations like are acceptable, though. -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 freed +with ``qemu_vfree()``, since breaking this will cause problems on Win32. String manipulation =================== -Do not use the strncpy function. As mentioned in the man page, it does *not* -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 does +*not* guarantee a ``NULL``-terminated buffer, which makes it extremely +dangerous to use. It also zeros trailing destination bytes out to the specified length. Instead, use this similar function when possible, but note its different signature: @@ -445,14 +447,14 @@ use this similar function when possible, but note its different signature: void pstrcpy(char *dest, int dest_buf_size, const char *src) -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: .. code-block:: c char *pstrcat(char *buf, int buf_size, const char *s) -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()``. QEMU provides other useful string functions: @@ -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) -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()``. -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()``. Printf-style functions ====================== @@ -525,10 +527,10 @@ automatic cleanup: Most notably: -* 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 scope -* 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 created + by a previous use of ``G_DEFINE_AUTOPTR_CLEANUP_FUNC``. This is supported for most GLib data types and GObjects For example, instead of @@ -552,7 +554,7 @@ For example, instead of return ret; } -Using g_autofree/g_autoptr enables the code to be written as: +Using ``g_autofree/g_autoptr`` enables the code to be written as: .. code-block:: c @@ -570,13 +572,13 @@ Using g_autofree/g_autoptr enables the code to be written as: While this generally results in simpler, less leak-prone code, there are still some caveats to beware of -* 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 -* 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``. .. code-block:: c From patchwork Thu Nov 18 14:57:16 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= X-Patchwork-Id: 1556712 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=DYOPCf1M; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org (client-ip=209.51.188.17; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4Hw31G2M5qz9sPf for ; Fri, 19 Nov 2021 02:02:10 +1100 (AEDT) Received: from localhost ([::1]:59940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mnivQ-0001jz-5s for incoming@patchwork.ozlabs.org; Thu, 18 Nov 2021 10:02:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnirA-0004xG-TY for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:45 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:37947) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mnir8-00084q-SC for qemu-devel@nongnu.org; Thu, 18 Nov 2021 09:57:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637247462; 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=995klPDX33rmzvSoWGVJ6V1EGfWuQDmUmdzVzSbmtDc=; b=DYOPCf1MAH4AZRv2mPWAdMXANcFKWX2DrYvM7xo5J8+o/gySe8IuA4qGu6u2OBW7T878NL Ubbi23eqhbx8bOsk9MeCgrIAGR9K1G37kboVQGBVsXwu/KbMfjhwah4nLobY3DZE0O6lnD x772ThSFMvKVcIcjMLh1SAY3sCMONqI= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-15-AvNbVFXKMqqJYEeMh2NZHQ-1; Thu, 18 Nov 2021 09:57:41 -0500 X-MC-Unique: AvNbVFXKMqqJYEeMh2NZHQ-1 Received: by mail-wm1-f72.google.com with SMTP id z126-20020a1c7e84000000b003335e5dc26bso2688389wmc.8 for ; Thu, 18 Nov 2021 06:57:40 -0800 (PST) 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=995klPDX33rmzvSoWGVJ6V1EGfWuQDmUmdzVzSbmtDc=; b=kRrPQQB1x5Llrg16pvOyISB9/RRTebIncxV2ZtfV7IIAM8NSATpcW+RFa5UKgu4IgA 2dmnYJhKIiCH+UWizJvDcd9Xu4jDRo6GJnbl9FNFXdetNW5rhOedAmJzj+LBtyGUYHjo GzcDRsJtgA2OLKCLicwWySVY06ir7UiJ/dLQt6PlNZ+unf+j3tNxkGAc52vQNXuq+9++ 7PKAH1ssV8KHmTaOUmZeJ+jO39E/Qg+3dR8edHmU4a+DC5DjsdMQfu2B2Q/GT5wMidU8 v30CJm4dco7DDpmQUj8ehtovIAKgXiQiLpQ1tcFXVZceDyhtSTyRc0YzwFiZTU/jc7q8 8tQw== X-Gm-Message-State: AOAM532ZE0W0jdKWgGRazdwz41Un8nLiwnrTmYsTu5NH/W1SkMMRRCOx w6gOQ1tfDMZ72ItgtAiwLna9VauWCiz6hP+BBE18xV0HjudroeQM1zLGBFqb7zYRS22vlBaXF7S go6DV8xg6xKsczZBoGgt+KjxXM8uz6laxAtoFOehTh9rZoTktxeit2JCyf9Rve/Jv X-Received: by 2002:adf:ce0e:: with SMTP id p14mr31229420wrn.423.1637247459428; Thu, 18 Nov 2021 06:57:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJyzA9z6QrKZQxNpKCdTMNZz5Kdu7G0oiAbK9lXyLgLEfb7M5V6ubx7stOrU/w/u2ubttfOFqQ== X-Received: by 2002:adf:ce0e:: with SMTP id p14mr31229388wrn.423.1637247459149; Thu, 18 Nov 2021 06:57:39 -0800 (PST) Received: from x1w.. (62.red-83-57-168.dynamicip.rima-tde.net. [83.57.168.62]) by smtp.gmail.com with ESMTPSA id q123sm9051755wma.30.2021.11.18.06.57.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Nov 2021 06:57:38 -0800 (PST) From: =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH-for-6.2? v2 5/5] docs/devel/style: Misc rST rendering improvements Date: Thu, 18 Nov 2021 15:57:16 +0100 Message-Id: <20211118145716.4116731-6-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 Received-SPF: pass client-ip=170.10.129.124; envelope-from=philmd@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -34 X-Spam_score: -3.5 X-Spam_bar: --- X-Spam_report: (-3.5 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?utf-8?q?Philippe_Mathieu-Dau?= =?utf-8?q?d=C3=A9?= , "Daniel P . Berrange" , Markus Armbruster , Darren Kenny Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée --- docs/devel/style.rst | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/devel/style.rst b/docs/devel/style.rst index 0397971e528..1db50b70544 100644 --- a/docs/devel/style.rst +++ b/docs/devel/style.rst @@ -4,7 +4,7 @@ QEMU Coding Style .. contents:: Table of Contents -Please use the script checkpatch.pl in the scripts directory to check +Please use the script ``checkpatch.pl`` in the scripts directory to check patches before submitting. Formatting and style @@ -195,9 +195,9 @@ blocks) are generally not allowed; declarations should be at the beginning of blocks. 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 declarations 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. Conditional statements @@ -220,13 +220,13 @@ even when the constant is on the right. Comment style ============= -We use traditional C-style /``*`` ``*``/ comments and avoid // comments. +We use traditional C-style ``/* */`` comments and avoid ``//`` comments. -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. 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: .. code-block:: c @@ -274,11 +274,11 @@ Order include directives as follows: #include "..." /* and finally QEMU headers. */ The "qemu/osdep.h" header contains preprocessor macros that affect the behavior -of core system headers like . It must be the first include so that -core system headers included by external libraries get the preprocessor macros -that QEMU depends on. +of core system headers like ````. It must be the first include so +that core system headers included by external libraries get the preprocessor +macros that QEMU depends on. -Do not include "qemu/osdep.h" from header files since the .c file will have +Do not include ``"qemu/osdep.h"`` from header files since the .c file will have already included it. C types @@ -352,9 +352,9 @@ casts, then reconsider or ask for help. Pointers -------- -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 @@ -505,7 +505,7 @@ painful. These are: the sign bit (ie it is an arithmetic shift, not a logical shift) 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. .. _autofree-ref: