Path: utzoo!attcan!uunet!lll-winken!ames!elroy!orion.cf.uci.edu!oberon!panarea.usc.edu!english
From: english@panarea.usc.edu (Joe English)
Newsgroups: comp.lang.c
Subject: Re: malloc impossible? (was: inkey$, noecho, and other impossibles)
Summary: "struct," too
Message-ID: <14658@oberon.USC.EDU>
Date: 13 Jan 89 04:26:58 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp> <9342@smoke.BRL.MIL> <15427@mimsy.UUCP>
Sender: news@oberon.USC.EDU
Reply-To: english@panarea.usc.edu (Joe English)
Distribution: na
Organization: University of Southern California, Los Angeles, CA
Lines: 50


In article <15427@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>In article <15406@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>>Actually, I was thinking about machines in which different types
>>>of objects must come from different address spaces (e.g., all
>>>`pointer' objects should be in the range 0x70000000..0x7c000000).
>
>In article <9342@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>>Such an implementation of malloc() must work if the C language works.
>>That's why I claim that malloc() is implementable on all architectures
>>for which an implementation of C is feasible.
>
>But I claim that, if the requirement for malloc() were dropped, one
>could implement C-minus-malloc on a machine that (say) required all
>floating point numbers to live in the floating-point address space,
>by having two stacks (one in the integer space and one in the fp space)
>and two data segments (likewise).  [....]

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?  

Also, from H&S (1984) section 5.7.3, "C compilers are constrained to
assign components increasing memory addresses in a strict
left-to-right order, with the first component starting at the
beginning address of the structure itself."  (What's the dpANS say on
this?)  This constraint would have to go.  Even so, that leaves a *lot*
of padding between different-typed fields :-)

It looks like C would be at the very least difficult, if not outright
impossible, to implement on this machine with or without malloc().
The "struct" semantics (and probably many others) would have to change
radically.  "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!


      /|/| Joe English
-----< | |
  O   \|\| english%lipari@oberon.usc.edu