From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, clemens@ladisch.de
Subject: Re: [PATCH v3 02/11] ALSA: firewire-lib/motu: use int type for the value of bitwise OR with enumerator-constant
Date: Tue, 18 May 2021 17:35:36 +0900 [thread overview]
Message-ID: <20210518083536.GA86229@workstation> (raw)
In-Reply-To: <s5him3gmovx.wl-tiwai@suse.de>
On Tue, May 18, 2021 at 10:23:30AM +0200, Takashi Iwai wrote:
> 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.
Ok. I just follow to the convention under the Linux kernel development.
Thanks
Takashi Sakamoto
next prev parent reply other threads:[~2021-05-18 8:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 2:43 [PATCH v3 00/11] ALSA: oxfw: code refactoring for quirks specific to ASICs Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 01/11] Revert "ALSA: bebob/oxfw: fix Kconfig entry for Mackie d.2 Pro" Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 02/11] ALSA: firewire-lib/motu: use int type for the value of bitwise OR with enumerator-constant Takashi Sakamoto
2021-05-18 7:02 ` Takashi Iwai
2021-05-18 8:13 ` Takashi Sakamoto
2021-05-18 8:23 ` Takashi Iwai
2021-05-18 8:35 ` Takashi Sakamoto [this message]
2021-05-18 2:43 ` [PATCH v3 03/11] ALSA: oxfw: code refactoring for existent device entry with specifier_id and version Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 04/11] ALSA: oxfw: code refactoring to detect Mackie models Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 05/11] ALSA: oxfw: add explicit device entry for Loud Technologies Tapco Link.FireWire 4x6 Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 06/11] ALSA: oxfw: add explicit device entry for Loud Technologies Mackie Onyx Sattelite Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 07/11] ALSA: oxfw: add comment for the type of ASICs Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 08/11] ALSA: oxfw: code refactoring for jumbo-payload quirk in OXFW970 Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 09/11] ALSA: firewire-lib: code refactoring for jumbo payload quirk Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 10/11] ALSA: oxfw: code refactoring for wrong_dbs quirk Takashi Sakamoto
2021-05-18 2:43 ` [PATCH v3 11/11] ALSA: oxfw: add quirk flag for blocking transmission method Takashi Sakamoto
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210518083536.GA86229@workstation \
--to=o-takashi@sakamocchi.jp \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.