Date: Wed, 16 Oct 2002 10:16:40 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Bruce Evans <bde@zeta.org.au> Cc: Jeffrey Hsu <hsu@FreeBSD.ORG>, net@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: RFC: eliminating the _IP_VHL hack. Message-ID: <69413.1034756200@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 16 Oct 2002 18:03:24 %2B1000." <20021016172019.W4358-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20021016172019.W4358-100000@gamplex.bde.org>, Bruce Evans writes: >On Tue, 15 Oct 2002, Jeffrey Hsu wrote: > >> > The side effect of having some source-files using the _IP_VHL hack and >> > some not is that sizeof(struct ip) varies from file to file, which at >> > best is confusing an at worst the source of some really evil bugs. > >There is no such effect, or ip would not work. s/,/ with our current compilers and architectures,/ >> > I would therefore propose to eliminate the _IP_VHL hack from the kernel >> > to end this state of (potential) confusion > >This would remove the least unportable version. Could be, but there is no point in us having two different versions, neither of which is guaranteed to be portable, in particular when one of the two is private to FreeBSD and not even consistently used there. For reference: NetBSD hasn't got the _IP_VHL but has a __packed__ on the structure. OpenBSD hasn't got the _IP_VHL either, but hasn't adopted the __packed__ from NetBSD. Linux also uses bitfields and endianess #ifdefs. >These workarounds are even more unportable than bit-fields. However, >there is no problem with struct ip yet, because everything is manually >packed to work with "all" C compilers on "all" systems. This will >break on systems with 64-bit ints, since sizeof(struct ip) == 20 is >not a multiple of 8. Good point. I'll ammend my proposal to include a __packed__ and a CTASSERT on the size of struct ip == 20. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?69413.1034756200>