From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9701BC433B4 for ; Tue, 18 May 2021 08:24:29 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 72DD9610A8 for ; Tue, 18 May 2021 08:24:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72DD9610A8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 3FDDC169A; Tue, 18 May 2021 10:23:36 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 3FDDC169A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1621326266; bh=y2erKtdMTYf6GAkBPz1fxRj1eobmol+kFwFW+TwdV8k=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=KhbVh/dK30z3CjAtAskiQpYuP1bWBT7o28zkZMT2gFdMCw3a0fbkArm6nX9UApENy si9FVhT18vEOyrshO+3VwaGJXNBXr+LFIMwgWSolshhTo3ShzPDik1B7qYo6FkFmsY zoHCAPC/X8PTHlfiPZ6wPfkf4opikDx+y14y1owg= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id ADF0EF801DB; Tue, 18 May 2021 10:23:35 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id CF580F80217; Tue, 18 May 2021 10:23:33 +0200 (CEST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 5A307F80139 for ; Tue, 18 May 2021 10:23:30 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 5A307F80139 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 6A8FAAC5B; Tue, 18 May 2021 08:23:30 +0000 (UTC) Date: Tue, 18 May 2021 10:23:30 +0200 Message-ID: From: Takashi Iwai To: Takashi Sakamoto Subject: Re: [PATCH v3 02/11] ALSA: firewire-lib/motu: use int type for the value of bitwise OR with enumerator-constant In-Reply-To: <20210518081334.GA84841@workstation> References: <20210518024326.67576-1-o-takashi@sakamocchi.jp> <20210518024326.67576-3-o-takashi@sakamocchi.jp> <20210518081334.GA84841@workstation> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: alsa-devel@alsa-project.org, clemens@ladisch.de X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Tue, 18 May 2021 10:13:34 +0200, Takashi Sakamoto wrote: > > On Tue, May 18, 2021 at 09:02:54AM +0200, Takashi Iwai wrote: > > On Tue, 18 May 2021 04:43:17 +0200, > > Takashi Sakamoto wrote: > > > > > > It brings some inconvenience in practice to use enumerated type for > > > variable to which bitwise OR with enumerator constant is assigned. > > > > > > This commit replaces declarations of enumerated type with int type. > > > > Better to use unsigned int for bit flags. Otherwise the highest bit > > becomes harder to use. > > I can't imagine such situation that the signed value causes issue. Would > I request actual example with such issue? At least, the highest bit is > still available as bit even if the value is negative by assigning > 0x80000000... It's available in signed int, but this is inconvenient, e.g. if you shift the bit. Maybe I forgot something else, too. You may still use signed int if you are sure that you'll never reach to the highest number, but other than that, using unsigned for bit flags is a *VERY* common practice in the kernel programming, so there is no reason to ignore it. Takashi