Path: utzoo!attcan!uunet!lll-winken!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: malloc impossible? (was: inkey$, noecho, and other impossibles)
Message-ID: <15456@mimsy.UUCP>
Date: 13 Jan 89 12:22:53 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp> <14658@oberon.USC.EDU>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 40

[same old perverse machine with integer and fp spaces]

In article <14658@oberon.USC.EDU> english@panarea.usc.edu (Joe English) writes:
>Then how would you do this:
>
>    struct impossible {
>        int   i;
>        float f;
>        double *dp;
>    } imp;
>
>Even if the compiler were to allocate the three components of imp in
>the approprate address spaces, what is &imp?  Does it point to imp.i,
>imp.f, or imp.dp? Or a vector of pointers (in the pointer address
>space, of course) which point to imp's components?  

It would have to point to a vector of pointers; the actual contents
of the structure would really be

	int	*i;
	float	*f;
	double	*dp;

(it is only necessary to add a reference level to simple objects).

Grotesque?  You bet!

>... "C-minus-malloc" wouldn't be much good unless it also provided a
>"new" operator -- I don't know about you, but *I* don't want to have to
>write my own malloc() routine along with every struct!

I agree.  But I think that a standards committee might shy away
from adding malloc to a C-like language that did not already have
malloc (in fact, they would almost certainly add a `new' instead).

Standards committtees tend to be overly conservative.  (Although they
can be radical sometimes, as witness `noalias'.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris