Path: utzoo!attcan!uunet!lll-winken!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: malloc impossible?
Message-ID: <9359@smoke.BRL.MIL>
Date: 13 Jan 89 06:00:55 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp> <9351@smoke.BRL.MIL> <15445@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <15445@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>And the code generated would be `allocate one object in each space,
>the double from F and the int from I' (that is, float and int spaces)
>rather than `allocate one object'.  References to the union would
>write both spaces; pointers to unions would be represented as pairs.

Then, due to other constraints on copyability of entire objects
via punned pointers etc., you would have to "shadow" the whole
dual-data space (except where a really clever compiler could
determine that it could get away with not doing so).  malloc()
would still be implementable.

Fortunately I don't know of any architectures quite like that.
Tagged architectures come close, but methods of faking them out
have been developed.