lkml.org 
[lkml]   [1999]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Q: void* vs. unsigned long
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.081 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site