On Tue, 4 Dec 2007, Max Laier wrote:
On Tuesday 04 December 2007, Alexey Dokuchaev wrote:
On Mon, Dec 03, 2007 at 04:57:33PM -0500, John Baldwin wrote:
On Monday 03 December 2007 10:24:52 am Dag-Erling Sm??rgrav wrote:
John Birrell <[EMAIL PROTECTED]> writes:
Log:
Fix strict alias warnings.
A much simpler solution (relative to the previous revision):
@@ -131,10 +131,10 @@
sum += oddbyte;
}
/* "Pseudo-header" data */
- ptr = (u_short *) & (pip->ip_dst);
+ ptr = (void *)&pip->ip_dst;
sum += *ptr++;
sum += *ptr;
- ptr = (u_short *) & (pip->ip_src);
+ ptr = (void *)&pip->ip_src;
sum += *ptr++;
sum += *ptr;
sum += htons((u_short) ntcp);
*ptr++ would choke since pointer arith on (void *) is undefined
AFAIK.
Um, ptr has type `u_short *', not `void *'. The original cast was
used to break a warning (and to add 3 style bugs). With stricter type
checking, it stopped "working". Now the warning is broken by casting
to `void *' which removes all knowledge of alignment restrictions and
I suppose must relax aliasing rules (else `void *' couldn't be used
for anything).
I've been under impression that ++ on void * whould simply increase it
by one.
This is a gcc bugfeature. It is disabled by -Wpointer-arith for FreeBSD
kernels.
wasn't that the reason why caddr_t exists? i.e. pointer arithmetic on
void * is bad, but on caddr_t it's kinda okay.
caddr_t is just an old mistake in this area. The kernel still hasn't
caught up with the post K&R-1 (1978) changes which introduced `void *'.
(A few places might need to represent "core" addresses that can't be
represented by `void *' due to separate address spaces or things like
PAE, but that problem is now handed by vm_^Woffset_t, vm_paddr_t and
vm_ooffset_t. caddr_t = `char *' has never been able to handle it.
"core" mostly means "mapped", so the problem doesn't affect most uses
of caddr_t.)
Bruce
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
