This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linux and aliasing?


   From: mark@codesourcery.com
   Date: Thu, 03 Jun 1999 10:40:38 -0700

   And David Miller (IIRC) indicated that the kernel folks would
   probably eliminate the non-standard C code in the next major kernel
   revision.

Actually, I've changed my mind, having to get rid of all such types of
casts inside the networking etc. is just an abomination.  There is no
reason anyone should have to use unions to teach the compiler about
what they're actually touching, if someone casts the thing they (the
programmer) know what they are doing, the compiler shouldn't assume
anything.

I'm not saying this should be the normal mode of operation, but some
mechanism needs to exist so that such code can be made valid _without_
resorting to ugly unions.  Consider our TCP hashing comparison code
in the kernel has gems like this:

#define TCP_IPV4_MATCH(__sk, __cookie, __saddr, __daddr, __ports, __dif)\
	(((*((__u64 *)&((__sk)->daddr)))== (__cookie))	&&		\
	 ((*((__u32 *)&((__sk)->dport)))== (__ports))   &&		\
	 (!((__sk)->bound_dev_if) || ((__sk)->bound_dev_if == (__dif))))

Sorry, I'm not using a union for this, it's totally a performance hack
and I'm not going to uglify the socket structure with silly unions.
And actually in this case, there is no reason the compiler cannot see
what I am up to.  Do powerful optimizations override common sense?

You know exactly what I'm doing there, and so do I, why can't egcs
figure it out that easily as well?

The compiler is just a tool.

Later,
David S. Miller
davem@redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]