| 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
| ||
|
Message-ID: <B28E9812BAF6E2498B7EC5C427F293A40114A6CB@orsmsx415.amr.corp.intel.com>
Date: Thu, 5 Oct 2006 15:14:02 -0700
From: "Moore, Robert" <robert.moore@...el.com>
To: "Moore, Robert" <robert.moore@...el.com>,
"Jan Engelhardt" <jengelh@...ux01.gwdg.de>,
"Andrew Morton" <akpm@...l.org>
Cc: "Len Brown" <lenb@...nel.org>, "Brown, Len" <len.brown@...el.com>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
"ACPI List" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH] Cast removal
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@...r.kernel.org [mailto:linux-acpi-
> owner@...r.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@...r.kernel.org [mailto:linux-acpi-
> > owner@...r.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@...r.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@...r.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@...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