Messages in this thread | | | Date | Mon, 15 Feb 1999 23:57:28 -0600 (CST) | From | Oliver Xymoron <> | Subject | Re: 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/
| |