lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 20 Nov 2013 11:14:12 -0500 From: Tejun Heo <tj@...nel.org> To: Alexander Gordeev <agordeev@...hat.com> Cc: linux-kernel@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>, Michael Ellerman <michael@...erman.id.au>, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Ben Hutchings <bhutchings@...arflare.com>, David Laight <David.Laight@...LAB.COM>, Mark Lord <kernel@...rt.ca>, "H. Peter Anvin" <hpa@...or.com>, linux-pci@...r.kernel.org Subject: Re: [PATCH RFC v2 08/29] PCI/MSI: Make pci_enable_msix() 'nvec' argument unsigned int Hello, On Fri, Oct 18, 2013 at 07:12:08PM +0200, Alexander Gordeev wrote: > Make pci_enable_msix() and pci_enable_msi_block() consistent > with regard to the type of 'nvec' argument. Indeed, a number > of vectors to allocate is a natural value, so make it unsigned. I'm personally not a big fan of using unsigneds where they're just used as numbers unless strictly necessary. They don't really provide any meaningful protection and we often end up in situations where we want to encode error conditions in the same type variable as return value or whatever and end up with silly situations like functions which take unsigned and returns integer or having a separate err variable when the high bit of the orignal variable would have worked just fine. Also, people have different thresholds for what should be unsigned and we end up with half things unsigned and the other signed. I'll defer the decision to Bjorn but I'd vote for converting things to int. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists