Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: malloc impossible? (unions)
Message-ID: <1404@mcgill-vision.UUCP>
Date: 28 Jan 89 09:29:54 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp> <9351@smoke.BRL.MIL>
Organization: McGill University, Montreal
Lines: 43

In article <9351@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <15427@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>> But I claim that, if the requirement for malloc() were dropped, one
>> could implement C-minus-malloc on a machine that (say) [had distinct
>> integer and float data and stack spaces]
> Assuming that integers could not also live in floating-point space, C
> would not be implementable on such a hypothetical architecture.
> Consider:   union { double d; int i; } u.d=123; printf("%d\n",u.i);
[example compressed -dM]
> This is required to work, although the specific value printed of
> course depends on details of numeric representation [...].

As I recall hashing out in email with someone-or-other a while ago,
there appears to be no requirement that u.d and u.i share any storage
at all.  That is, the printed value need not bear any relation at all
to the bit pattern used to represent the double-floating value 123.

Is it really required to even print anything?  K&RV2 says the results
"are implementation-dependent if something is stored as one type and
extracted as another".  Does the Proposal say anything essentially
different?  Sounds as though "Segmentation fault - core dumped" is a
technically legal response.  (More likely, something like "CChecker:
warning: wrong type retrieved from union at line 5" :-)

Someone else mentioned memcpy() and related routines as being another
reason C wouldn't be implementable on such an architecture.  Is this
really true?  The arguments will be cast to void *, but I can't find
any requirement that the resulting pointers can be (re-cast and)
dereferenced meaningfully as any type but the original type.  Indeed, I
find no requirement that the following print 0 rather than 1:

main() { int i; float f; printf("%d\n",((void *)&i)==((void *)&f)); }

(My reference is K&RV2; until machine-readable copies of the draft or
proposal or standard or whateveritisthisweek become available, it will
remain so.  I mean, really, presumably this standard is supposed to be
used, so what do they do but refuse to use the best available means of
inews: flames inappropriate for this group - posting truncated

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu