Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: pointer-to-integer Message-ID: <5958@brl-smoke.ARPA> Date: Fri, 5-Jun-87 02:36:12 EDT Article-I.D.: brl-smok.5958 Posted: Fri Jun 5 02:36:12 1987 Date-Received: Tue, 9-Jun-87 02:36:42 EDT References: <158@delftcc.UUCP> <3673@gitpyr.gatech.EDU> <414@sds.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 20 In article <414@sds.UUCP> dave@sds.UUCP (dave schmidt x194) writes: >I thought the C language guaranteed that there was an integral type >large enough to hold any pointer type. No, as of the dpANS pointer<->integer conversions need not even be supported by an implementation. If they ARE supported, there are certain constraints on the semantics. It wouldn't make much sense to support pointer<->integer unless there were an integer type for which no significant bits of the pointer would be lost. By the way, such a converted integer need not correspond in any particular way to linear addresses, so long as the mapping is invertible. I just went through this while de-linting the Bourne shell; it has its own memory allocator and uses a spare "busy" flag bit in converted pointers. Unfortunately word-addressed machines like the Crays may not have the low-order bit free, even when the pointers are aligned to multiples of some object size (e.g. 8 bytes). If you write code like this, first of all shame on you, but secondly, please be aware that the low bit of a converted pointer might be significant.