On Sat, 13 Sep 2003 21:59:37 +0200
Bart De Schuymer <bdschuym@xxxxxxxxxx> wrote:
> It just uses unsigned int instead of unsigned long, so there should
> be no problem with the evil Sparc64.
Sparc64 doesn't have the problems, it just fixes up the unaligned
accesses there so it'll just be super-slow (some "optimization" :).
The problem is on parisc64 which is very strict about accessing
structure members which are not aligned to the accessor type you use
to dereference and gives you a link/compile error when you violate
this.
> Perhaps the ip_tables.c code from which I copied the original code
> should be altered too.
Yes.
> It's a real optimization btw, the .o file is 32 bytes
> larger when doing the bit operations on a char with i<IFNAMSIZ.
> All hail Rusty :)
I understand, but instead create an arch routine to optimize this
instead of using non-portable constructs. memcmp_masked() or
something like that.
|