Date: Thu, 1 Jul 2004 16:32:32 +0100 From: Anil Madhavapeddy <anil@recoil.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: net@FreeBSD.org Subject: Re: Packing netgraph structs Message-ID: <DE6B62C9-CB73-11D8-99F8-000A95DA50A6@recoil.org> In-Reply-To: <20040701141056.GA45665@ip.net.ua> References: <122AE07F-CB5B-11D8-99F8-000A95DA50A6@recoil.org> <40E40839.20500@cronyx.ru> <931572E3-CB5E-11D8-99F8-000A95DA50A6@recoil.org> <20040701141056.GA45665@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1 Jul 2004, at 15:10, Ruslan Ermilov wrote: > We use Netgraph from within Python, using the netgraph(3) library, > and we pack/unpack various Netgraph related structs just happily. > > Speaking of "struct ng_mesg", if you pack it, it will essentially > stay the same, because I believe it was created with this in mind, > as well as most if not all other user-accessible Netgraph structs. How robust is this solution? Since ng_mesg uses nested structs, and compilers can insert padding at the end of structs at will, this could lead to padding between ng_mesg.header.cmdstr and ng_mesg.data. Alan Mycroft, who wrote the ARM C compiler commented that the C spec is rather ambiguous about padding, and that compilers are quite free to pad as they chose in between structs as well. In other words - is there any harm in adding a packed attribute here to ensure this wont break and lead to hard to track down bugs in the future? It shouldn't even affect the gcc ABI I think ... ? For the moment, I'll get on with just serialising as if it were optimally packed from OCaml, thanks for your help so far! -- Anil Madhavapeddy http://anil.recoil.org University of Cambridge http://www.cl.cam.ac.uk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DE6B62C9-CB73-11D8-99F8-000A95DA50A6>