Date: Wed, 16 Oct 2002 23:30:21 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Stefan Farfeleder <e0026813@stud3.tuwien.ac.at> Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: kern/44121: [PATCH] bogus cast removal in hea driver Message-ID: <20021016230026.X5394-100000@gamplex.bde.org> In-Reply-To: <200210152200.g9FM0BTD065191@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Oct 2002, Stefan Farfeleder wrote: > The following reply was made to PR kern/44121; it has been noted by GNATS. > > From: Stefan Farfeleder <e0026813@stud3.tuwien.ac.at> > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/44121: [PATCH] bogus cast removal in hea driver > Date: Tue, 15 Oct 2002 23:51:10 +0200 > > My "fix" isn't really all that good, since gcc now complains about > losing const. So I think the pointer should be cast to void *. The same > applies to eni_buffer.c:127 btw. Sorry. I rather like it, since it removes one layer of bogusness. Casting to `void *' would have no effect, since this is done implicitly because bcopy() takes a `void *' arg, and -Wcast-qual forcing the same warnings about the explicit cast as -Wno-cast-qual gives for the implicit cast. The layers of bogusness here are: - the driver actually declares volatile memory as being volatile. Such care can do more harm than good when the compiler actually enforces volatileness. - the driver wants to pass a pointer to volatile memory to bzero(). This gives undefined behaviour, because bzero() takes a pointer to nonvolatile memory. At least the i586-optimized version of bzero() does things that might be bad for volatile memory (it sometimes writes to the same memory twice ...). - the pointer is cast to uintptr_t in an attempt to hide this problem. - the file is declared as "nowerror" in conf/files to ignore this problem. The correct fix is probably to use bus space more and never access device memory through C pointers (except in low-level code). Bus space is magic and the low-leel code knows this and avoids doing things that would be bad for volatile memory in the memory-mapped i/o case. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021016230026.X5394-100000>