Date: Mon, 13 Feb 2006 00:23:10 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: ertr1013@student.uu.se Cc: des@des.no, stefanf@freebsd.org, arch@freebsd.org Subject: Re: [releng_6 tinderbox] failure on sparc64/sparc64 Message-ID: <20060213.002310.125802352.imp@bsdimp.com> In-Reply-To: <20060205220211.GA5151@falcon.midgard.homeip.net> References: <20060205084813.GN21806@wombat.fafoe.narf.at> <867j89n71d.fsf@xps.des.no> <20060205220211.GA5151@falcon.midgard.homeip.net>
index | next in thread | previous in thread | raw e-mail
In message: <20060205220211.GA5151@falcon.midgard.homeip.net>
Erik Trulsson <ertr1013@student.uu.se> writes:
: On Sun, Feb 05, 2006 at 04:45:34PM +0100, Dag-Erling Smørgrav wrote:
: > Stefan Farfeleder <stefanf@FreeBSD.org> writes:
: > > On Sat, Feb 04, 2006 at 03:58:56PM -0700, M. Warner Losh wrote:
: > > > This driver wants to access these structures as arrays of uint32_t.
: > > > It used to cast directly, but that isn't allowed. So, I've passed
: > > > the cast through a (void *). Is that allowed? Eg:
: > > >
: > > > struct foo foo;
: > > > ((uint32_t *)(void *)&foo)[3] = 12;
: > > >
: > > > is that OK?
: > > I'm afraid that only silences the warning without solving the underlying
: > > problem. I don't think there's a Standard conforming way to treat a
: > > struct foo as an uint32_t array.
: >
: > A union should do the trick.
:
: No, it will not. If you have a struct foo and try to access it as an array
: of int, the program will have unspecified (and maybe even undefined)
: behaviour. It does not matter if you do it with a union or by casting
: pointers.
:
: In general, if you have an object of type X, then the only ways it can be
: accessed is either as an object of type X, or as an array of [unsigned]
: char.
So the proper fix for the above code is:
struct foo foo;
uint32_t value[sizeof(foo) / sizeof(uint32_t)];
memcpy(value, &foo);
// write out value one 32-bit word at a time
Is that right? Or at least 'proper' here means defined.
Warner
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060213.002310.125802352.imp>