Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp5191262imd; Tue, 30 Oct 2018 13:26:44 -0700 (PDT) X-Google-Smtp-Source: AJdET5ferKSJXyvKi7NqDIbizFr0YMkS3zYPZZtksfaovH++ml21Gpw1icnieIO6YLglH70RHyrC X-Received: by 2002:a63:5c16:: with SMTP id q22-v6mr164323pgb.417.1540931204559; Tue, 30 Oct 2018 13:26:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540931204; cv=none; d=google.com; s=arc-20160816; b=iq6LCPbBMXAnPfEfccU7jFSAuQGpZbL4ykwXp+ugBrpPmUJgrW/Qyg8oI0CTZH2YRR YGKbMuyqCGAV8oqzrs2saNyH3xJrjg86v6A0AflD4Y4vpV9zJnYoBEPv29489JHfu8Id AXaH3Bq7S3yfa+VrmVJQjh38K/MQpjfCQ1j9j0TZI4ZvSMlSq/JMY33w7TaxUYtd9CUo ujGuHalBPN4uu/fyDmT05QzM3E9I/ooAJTncaBYA+CmARHW1cQ1+gX6DZ3+L9XKE+Lce /gxB33kBknDWmn8f4N/DQVrnQWVGnWKgHZbAX50MBmCA6aBvN3PPgYchoAJakGbJc8xC RhDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=UgJnORwgO+QuRDcafDyAztCd93xQMyEdLxV+WNkWvz4=; b=wxTaN3p8XQCUQZcgmgoy1IpNNumeluvep24ekh/+cZM21Z0rTAr2v36sDJPHw6+ELI CdS2H1X/3jp30y+mIsAU1JDodx09BYF87ffetoILKaTNpIdXvhgeWB0R/qTtTLzC3ZJk 6ReHqSIWrK95YCGDLfSSMl9knkCkPlUP52T5AMTQZunwVmO1SshD9Fij3ciPMROkUoz6 jUPesI9Xu7s+yk6kDVHWZeLqhCCufL65IPn4yfcrqUIS5yXU4awxzZO8sl4Ob36lADrd RiQ+BJltnYjq7uBypGM7bAlMi/60SR3EzoPUX/qz8NuOwU7BeZa8mNmO0EVGrDSMMuEI Zy0A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p5-v6si23463065plo.363.2018.10.30.13.26.29; Tue, 30 Oct 2018 13:26:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726026AbeJaFUP (ORCPT + 99 others); Wed, 31 Oct 2018 01:20:15 -0400 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:43255 "EHLO mail2-relais-roc.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725765AbeJaFUP (ORCPT ); Wed, 31 Oct 2018 01:20:15 -0400 X-IronPort-AV: E=Sophos;i="5.54,445,1534802400"; d="scan'208";a="353523191" Received: from 89-157-201-244.rev.numericable.fr (HELO hadrien) ([89.157.201.244]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2018 21:25:15 +0100 Date: Tue, 30 Oct 2018 21:25:15 +0100 (CET) From: Julia Lawall X-X-Sender: jll@hadrien To: Shayenne Moura cc: Himanshu Jha , Sasha Levin , Greg Kroah-Hartman , Hans de Goede , Michael Thayer , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, outreachy-kernel@googlegroups.com Subject: Re: [Outreachy kernel] [RESEND PATCH 2/2] staging: vboxvideo: Use unsigned int instead bool In-Reply-To: <20181030201816.joihhwd7htgixo5i@smtp.gmail.com> Message-ID: References: <211701e4ae42acd95afb24713314bce5a4c58ecf.1540580493.git.shayenneluzmoura@gmail.com> <20181026204225.GH2015@sasha-vm> <20181028075209.GA1938@himanshu-Vostro-3559> <20181028112011.GA5157@himanshu-Vostro-3559> <20181030201816.joihhwd7htgixo5i@smtp.gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Oct 2018, Shayenne Moura wrote: > Hi, > > > On Sun, 28 Oct 2018, Himanshu Jha wrote: > > > > > On Sun, Oct 28, 2018 at 09:47:15AM +0100, Julia Lawall wrote: > > > > > The "possible alignement issues" in CHECK report is difficult to figure > > > > > out by just doing a glance analysis. :) > > > > > > > > > > Linus also suggested to use bool as the base type i.e., `bool x:1` but > > > > > again sizeof(_Bool) is implementation defined ranging from 1-4 bytes. > > > > > > > > If bool x:1 has the size of bool, then wouldn't int x:1 have the size of > > > > int? But my little experiments suggest that the size is the smallest that > > > > fits the requested bits and alignment chosen by the compiler, regardless of > > > > the type. > > > > > > Yes, correct! > > > And we can't use sizeof on bitfields *directly*, nor reference it using a > > > pointer. > > > > > > It can be applied only when these bitfields are wrapped in a structure. > > > > > > Testing: > > > > > > #include > > > #include > > > > > > struct S { > > > bool a:1; > > > bool b:1; > > > bool c:1; > > > bool d:1; > > > }; > > > > > > int main(void) > > > { > > > printf("%zu\n", sizeof(struct S)); > > > } > > > > > > Output: 1 > > > > > > If I change all bool to unsigned int, output is: *4*. > > > > > > So, conclusion is compiler doesn't squeeze the size less than > > > native size of the datatype i.e., if we changed all members to > > > unsigned int:1, > > > total width = 4 bits > > > padding = 4 bits > > > > > > Therefore, total size should have been = 1 byte! > > > But since sizeof(unsigned int) == 4, it can't be squeezed to > > > less than it. > > > > This conclusion does not seem to be correct, if you try the following > > program. I get 4 for everything, meaning that the four unsigned int bits > > are getting squeezed into one byte when it is convenient. > > > > #include > > #include > > > > struct S1 { > > bool a:1; > > bool b:1; > > bool c:1; > > bool d:1; > > char a1; > > char a2; > > char a3; > > }; > > > > struct S2 { > > unsigned int a:1; > > unsigned int b:1; > > unsigned int c:1; > > unsigned int d:1; > > char a1; > > char a2; > > char a3; > > }; > > > > int main(void) > > { > > printf("%zu\n", sizeof(struct S1)); > > printf("%zu\n", sizeof(struct S2)); > > printf("%zu\n", sizeof(unsigned int)); > > } > > > > > Well, int x:1 can either have 0..1 or -1..0 range due implementation > > > defined behavior as I said in the previous reply. > > > > > > If you really want to consider negative values, then make it explicit > > > using `signed int x:1` which make range guaranteed to be -1..0 > > > > The code wants booleans, not negative values. > > > > julia > > Thank you all for the discussion! > > However, I think I do not understand the conclusion. > > It means that the best way is to use only boolean instead of use unsigned > int with bitfield? I mean specifically in the case of my patch, where there > are some boolean variables are mixed with other variables types. To my recollection, your code had a bool with larger types on either side. In that case, I think bool is fine. The compiler it likely to align those larger typed values such that the field with the bool type will get more than one byte no matter what type you use. If there are several fields with very small types adjacent, there might be some benefit to thinking about what the type should be. julia