RE: [PATCH] Cast removal

["Moore, Robert" <robert.moore@intel.com>]

If you're discussing this type of thing, I agree wholeheartedly:

static void acpi_processor_notify(acpi_handle handle, u32 event, void
*data)  {
-	struct acpi_processor *pr = (struct acpi_processor *)data;
+	struct acpi_processor *pr = data;


I find this one interesting, as we've put a number of them into the
ACPICA core:

-	(void) kmem_cache_destroy(cache);
+	kmem_cache_destroy(cache);

I believe that the point of the (void) is to prevent lint from
squawking, and perhaps some picky ANSI-C compilers. What is the overall
Linux policy on this?

Thanks,
Bob


> -----Original Message-----
> From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> owner@vger.kernel.org] On Behalf Of Moore, Robert
> Sent: Thursday, October 05, 2006 8:46 AM
> To: Jan Engelhardt; Andrew Morton
> Cc: Len Brown; Brown, Len; Linux Kernel Mailing List; ACPI List
> Subject: RE: [PATCH] Cast removal
> 
> I was speaking generally, as far as casting issues go with ACPICA. We
> have lots of compilers to support, as well as 16/32/64 bit issues. We
> are about to remove the 16-bit support, which will clean things up a
> bit.
> 
> I would appreciate a couple of examples of exactly what is being
> discussed.
> Thanks.
> Bob
> 
> 
> > -----Original Message-----
> > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi-
> > owner@vger.kernel.org] On Behalf Of Jan Engelhardt
> > Sent: Thursday, October 05, 2006 1:00 AM
> > To: Andrew Morton
> > Cc: Len Brown; Brown, Len; Linux Kernel Mailing List; ACPI List
> > Subject: Re: [PATCH] Cast removal
> >
> >
> > >> > > I'm okay applying this patch it touches the linux-specific
> > >> > > drivers/acpi/* files only, no ACPICA files.
> > >> >
> > >> > Why?
> > >>
> > >> Why am I okay with it?
> > >
> > >No, I meant why not clean up ACPICA too?
> >
> > I was about to go through the whole kernel base for anti-casting.
> Sounds
> > like a big task, and probably is. I just did not want to do it all
at
> > once and send a mega-patch. Instead, a per-directory walk seems best
> to
> > me, and granted, "dispatcher events executer hardware namespace" and
> all
> > the other directories under drivers/acpi/ were supposed to be the
next
> > to be examined for casts.
> >     Though if you have problems with that because compiling with
ugh,
> > old or broken, compilers, be my guest.
> > http://www.velocityreviews.com/forums/t313918-void-casting.html
> > """If your compiler requires a cast, you are using a C++
compiler."""
> > Is that the case?
> >
> >
> >
> > 	-`J'
> > --
> > -
> > To unsubscribe from this list: send the line "unsubscribe
linux-acpi"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/