| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH 1/4] x86: remove cast from void*
|
To: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [PATCH 1/4] x86: remove cast from void* |
|
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Date: |
Tue, 14 Sep 2010 11:46:47 -0700 |
|
Cc: |
xen-devel@xxxxxxxxxxxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxxxxxxx>, matt mooney <mfm@xxxxxxxxxxxxx>, x86@xxxxxxxxxx, kernel-janitors@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Ingo Molnar <mingo@xxxxxxxxxx>, Tejun Heo <tj@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx> |
|
Delivery-date: |
Tue, 14 Sep 2010 11:47:24 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4C8FBD01.40900@xxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<1284441511-11511-1-git-send-email-mfm@xxxxxxxxxxxxx> <4C8FB5C3.3050806@xxxxxxxx> <4C8FBD01.40900@xxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.8) Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2 |
On 09/14/2010 11:20 AM, H. Peter Anvin wrote:
> On 09/14/2010 10:49 AM, Jeremy Fitzhardinge wrote:
>> On 09/13/2010 10:18 PM, matt mooney wrote:
>>> Unnecessary cast from void* in assignment.
>> Not very keen on this. The cast may not be strictly required, but it
>> does document what's going on there.
>>
> But unnecessary casts are problematic in that if the type changes, they
> can hide a real bug in the future.
If page->private changes in a way which invalidates this kind of usage,
I would hope it would also change name to something more descriptive of
its new role. If it changes type but is broadly compatible with this
usage (say, void * -> unsigned long), then the cast won't matter, or
will become a requirement.
I'm more concerned about "user_ptr" changing type, in which case the
cast will highlight the problem.
In general, the casts from these kinds of generic/polymorphic fields let
you easily eyeball how they're being used, without having to work out
what the type of the other side is.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home