From: Greg KH <gregkh@suse.de>
To: Greg Dietsche <gregory.dietsche@cuw.edu>
Cc: Alan Stern <stern@rowland.harvard.edu>,
mfuzzey@gmail.com, tom.leiming@gmail.com, ak@linux.intel.com,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: fix warning in usbtest module
Date: Sun, 8 May 2011 15:58:47 -0700 [thread overview]
Message-ID: <20110508225847.GA12750@suse.de> (raw)
In-Reply-To: <4DC6EB3B.8070604@cuw.edu>
On Sun, May 08, 2011 at 02:12:59PM -0500, Greg Dietsche wrote:
> On 05/08/2011 09:37 AM, Alan Stern wrote:
> >On Sat, 7 May 2011, Greg Dietsche wrote:
> >
> >>On amd64 unsigned is not as wide as pointer and this causes
> >>a compiler warning. Switching to uintptr_t fixes the problem
> >>in an arch independent manner.
> >People tend to prefer to see non-typedef'ed type names, whenever
> >possible. In this case, it would be enough to change the type to
> >unsigned long.
> >
> >Lots of code throughout the kernel stores pointer values in unsigned
> >long variables. I've never heard any recommendation for using
> >uintptr_t instead.
> >
> I was leaning towards unsigned long at first too, but a several
> things made me reconsider:
> 1) uintptr_t adapts correctly to the size of a pointer on all
> architectures per C99
> 2) I greped the kernel source and found a number of instances where
> uintptr_t is used
> 3) unsigned long is technically too wide (though this is better than
> too small...) for some architectures
>
> If the general consensus is that unsigned long is a better choice
> for the kernel, I will update my patch. I do, however think that
> uintptr_t is the best choice from a technical perspective and prefer
> it over unsigned long.
Sorry, but no, use 'unsigned long' please. In the kernel, it's
guaranteed to hold the size of a pointer, that is one of the
requirements of Linux.
And as for C99, those types don't make any sense in the kernel, only in
userspace. See Linus's posts on this a few years back on lkml if you
want all of the details.
So please redo this patch with 'unsigned long' and I will be glad to
queue it up.
thanks,
greg k-h
next prev parent reply other threads:[~2011-05-09 3:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-08 3:27 [PATCH] usb: fix warning in usbtest module Greg Dietsche
2011-05-08 14:37 ` Alan Stern
2011-05-08 19:12 ` Greg Dietsche
2011-05-08 22:58 ` Greg KH [this message]
2011-05-09 3:51 ` [PATCH] usb: fix warning in usbtest module v2 Greg Dietsche
2011-05-09 4:02 ` [PATCH] usb: fix warning in usbtest module Greg Dietsche
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=20110508225847.GA12750@suse.de \
--to=gregkh@suse.de \
--cc=ak@linux.intel.com \
--cc=gregory.dietsche@cuw.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mfuzzey@gmail.com \
--cc=stern@rowland.harvard.edu \
--cc=tom.leiming@gmail.com \
/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.