Path: utzoo!attcan!uunet!husc6!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: A cast pointer is NOT an lvalue!? (ANSI C)
Keywords: X3J11, pointers, cast, lvalue
Message-ID: <9560@haddock.ima.isc.com>
Date: 18 Oct 88 00:01:44 GMT
References: <479@midgard.mn.org> <8663@smoke.ARPA> <482@midgard.mn.org> <14005@mimsy.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 17

In article <14005@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <482@midgard.mn.org> dal@midgard.mn.org (Dale Schumacher) asks:
>>... If an implementation stores different object types in different
>>areas of memory, then wouldn't that fail also?  How would one implement
>>malloc() on such a machine?
>
>The short answer is `one would not'.  The long one is that maybe it
>would work if the compiler recognised allocation calls (malloc, calloc)

On such an implementation, malloc() is not your only problem.  What about a
pointer which is (legally) cast to a less strictly aligned type and back
again?  What about a struct containing two different object types?

I think it's safe to say that no C implementation would depend on such type
segregation.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint