Re: Q: void* vs. unsigned long

Oliver Xymoron (oxymoron@waste.org)
Mon, 15 Feb 1999 23:57:28 -0600 (CST)


On Mon, 15 Feb 1999, H. Peter Anvin wrote:

> > And probably a couple 16-bit systems as well. But that's just
> > coincidence. For instance, if the 386 wasn't so woefully register-impaired,
> > unsigned long would be 64-bit. And I'd bet a quarter that sizeof(void *)
> > will not be 16 on a 128-bit machine (when we finally see one).
> >
> > But what we need here is "an integral type which can represent all
> > possible pointer values". Unsigned long should be safe for that on all
> > sane architectures/compilers[1] and might even be guaranteed by the C
> > standard. Probably won't work on all DSPs though, but we're not likely to
> > see any of those running Linux soon for other reasons.
> >
>
> I've personally been fond of poi_t (pointer or integer _t):
>
> typedef union {
> void *p;
> signed long s;
> unsigned long u;
> } poi_t;
>
> ... or the respective. Of course, if one doesn't like unions, one can
> do the same thing as a typedef to the integral type.

One doesn't like unions and uses them sparingly. Which reminds me, even
though unsigned long is safe, a per-arch typedef of some sort is still a
cleaner implementation, as you may end up with an arch where
sizeof(int)==sizeof(long)/2==sizeof(void *) and longs are less efficient
than ints. 16-bit x86 is one example, and I expect we'll see more when we
get over the 64-bit horizon.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/