Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!milton!ogicse!intelhf!ichips!iwarp.intel.com!inews!pima!bhoughto
From: bhoughto@pima.intel.com (Blair P. Houghton)
Newsgroups: comp.lang.c
Subject: Re: increment casted void pointer  --  ANSI?
Message-ID: <3548@inews.intel.com>
Date: 29 Mar 91 06:29:38 GMT
Article-I.D.: inews.3548
References: <15589@smoke.brl.mil> <3492@inews.intel.com> <15619@smoke.brl.mil>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 32

In article <15619@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>Sure it "overlaps", or acts as if it did.  A conforming implementation
>that, e.g. stores floating-point data in a different address space from
>integer data may have to jump through hoops if it wishes to make the
>aliasing of the representations actually work.  However, such a program
>would have to be successfully translated, it just may not work right (in
>which case the fake pointer business would probably malfunction too).

But does this guarantee that you can retrieve the bits of a
member of one type simply by accessing using a different-typed
rvalue?

E.g.

	union {
	    int i;
	    float f;
	} x, *y;
	float z;

	x.i = 4;
	y = &x;
	z = y->f;

It seems to me that this is nowhere permitted to return
the bits of `4' in the float-value, nor prohibited from it.
(I doubt very much that it would return `4.0').  Sure it'd
be a cute thing to have around, but can one _rely_ on it
and claim portability re X3.159-1989?

				--Blair
				  "The standard is undefined..."