From nobody Mon Feb 9 18:19:37 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=1637247447; cv=none; d=zohomail.com; s=zohoarc; b=a171EpAmUyi2OHa6SpuwiLAu/GtorK5e1F/7ncBw3Zb3PHEZtpxD4jr5fPiv4uMjtsyXaDLmm7dKBRR68tZMo7SROeH1pTCMZBVzLgbSBhRaKqZLrzj1B8uXRX5bJaGj1Nvg41gTke6kbrp5aFCvZ0Wu+cnqTA9XSZpzMP6pCc8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1637247447; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=/sBYOa2h22qqCaXNmWikjc24bg3qqY1FNjgkcCrf8RE=; b=iYg50tggjUgWO4ijW/J+EQSSzgjfNHmh/BxxTZ3kRm8s0VBEtzXUbEomE4cYzgiGb67ZWzICcVJUVsKNKx4fQ7urL+EYoVVtNTltPeUNlbJA+jxmCAPi/7yWQicdAv1/5J044DnCbDnDKcqnsYlyCncne7QSwca1QmdTA0vUonU= 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 1637247447419746.8877429158861; Thu, 18 Nov 2021 06:57:27 -0800 (PST) Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-266-Cd8zA79WN7SyGy9GcAz-uw-1; Thu, 18 Nov 2021 09:57:24 -0500 Received: by mail-wm1-f69.google.com with SMTP id ay34-20020a05600c1e2200b00337fd217772so3241552wmb.4 for ; Thu, 18 Nov 2021 06:57:23 -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 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637247445; 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=RILYiTPbnr4yMxMhaKTr1ibSXtbXtlRZ6l3+anpsnx2dH1qsA5clG2RHYLcmWNGSVuo/zW ANaDuif5N3z8LV9qfeLRd54jIyFXMMdv/Mv/ryKEwxoX/+GSlZzC/t17RKG3Q13fKntyE1 2tygoTwlJBX9qzyxX1oBk3E/oNCLa7E= X-MC-Unique: Cd8zA79WN7SyGy9GcAz-uw-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=/sBYOa2h22qqCaXNmWikjc24bg3qqY1FNjgkcCrf8RE=; b=djzJS7mIBqJdWF5pZwcKAtcrE4eXBwsyp3ccbBHGeYSIzwi4Cz33RbnSKiwMVjVxsb UQaUP75tQtARQUmTrYzFfvFSJmLLVf/9KVT40Oq7Pv+4iOZQKykqCX/u/GubDtAnJ+k9 gSSopSlCC2QSNmoS8IRl4RIyOALcKCowOqf3Ew1Sro+J58JCRUho1B9GVYV10yNSj2GQ 5nk4JaUnTyxm6ZcaGTmz6tWPckYPp1w7YGHxAh0bkVsWfE/YnFTizzy8ziIYJK2pGsN+ CLOO1PiZIC+2MNNCC2OxAi8a4bWTlb67kdoA1/oHg+T2FH5vqgIOTrzR5ZLFlGyyeoFD VhMg== X-Gm-Message-State: AOAM5300TlqyqDoWxyBkqxM99uc0AM/uOd+cX9o3auPsqT3ls0NO5SaY 9cwbKpkWMHHIcZ5H4W0QMdx6uhA373I1A2kNAK85IbZwYSmkpmeRg4XmfN2RdHnG3/QbzPU9x83 Pweb6dizAxEznZA== X-Received: by 2002:a05:6000:181:: with SMTP id p1mr31961473wrx.292.1637247442326; 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) 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 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1637247448565100001 Signed-off-by: Philippe Mathieu-Daud=C3=A9 Reviewed-by: Alex Benn=C3=A9e --- 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. =20 Variable Naming Conventions @@ -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. @@ -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. @@ -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 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 --=20 2.31.1