[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (no) strict aliasing

From: Marcus Brinkmann
Subject: Re: (no) strict aliasing
Date: Mon, 01 Nov 2004 02:59:49 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Mon, 01 Nov 2004 02:41:52 +0100,
Marcus Brinkmann wrote:
> it.  It makes it more difficult to extend library-managed objects
> dynamically in the way we want to do it.  (The only way I can think of
> is to push the allocation to the higher level, and assign it to the
> biggest object first, then derive the pointers to the sub objects.
> Ie, only cast downwards the object hierarchy).

Another possibility is of course to return a pointer to the
(uninitialized) user data and store the library-internal data right
before that:

                  library internal data
object pointer -> user data

And then access the library internal data by subtracting its size.
This play with pointer and pointer arithmetic is apparently valid
code, because it deals with two distinct objects with distinct types
at distinct memory locations.

It uglifies the code, but on the plus side, it makes the library
internal data potentially more opaque (personally, I'd still want to
export it so that some accesses to the internal data can be inlined).

Most certainly I will wake up in a couple of hours and regret having
written that, because I find some basic mistake in this approach, or
for some other reason.  Still, having jumped the gun in complaining
about the whole issue I thought I'd compensate with a couple of ideas
how it could be done "right".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]