Date: Mon, 13 Feb 2006 20:38:34 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: arch@freebsd.org, stefanf@freebsd.org, Colin Percival <cperciva@freebsd.org>, des@des.no Subject: Re: [releng_6 tinderbox] failure on sparc64/sparc64 Message-ID: <20060213093833.GB705@turion.vk2pj.dyndns.org> In-Reply-To: <20060213084802.GA53779@flame.pc> References: <20060205084813.GN21806@wombat.fafoe.narf.at> <867j89n71d.fsf@xps.des.no> <20060205220211.GA5151@falcon.midgard.homeip.net> <20060213.002310.125802352.imp@bsdimp.com> <20060213082129.GA13997@flame.pc> <43F04494.4030900@freebsd.org> <20060213084802.GA53779@flame.pc>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2006-Feb-13 10:48:02 +0200, Giorgos Keramidas wrote: >Good thinking. It's probably a good idea to avoid copying random >garbage, and using something like: > > struct foo foo; > uint32_t value[sizeof(uint32_t) * (sizeof(foo) / sizeof(uint32_t) + 1)]; That makes it about 4 times too large - you don't need to multiply by sizeof(uint32_t). >and then copying only sizeof(foo) bytes. And zeroing any remaining bytes to prevent uninitialised data leaking out of the kernel. >and won't allow overflowing of value[], but I don't really want to know >what it does on machines of varying endianess :-) No worse than trying to write (uint32_t *)&foo; BTW, the compiler is free to insert padding bytes into struct foo so it would need to be explicitly zeroed and then the required fields individually copied in. -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060213093833.GB705>