Path: utzoo!utgpu!water!watmath!clyde!burl!codas!killer!jfh
From: jfh@killer.UUCP (John Haugh)
Newsgroups: comp.lang.c
Subject: Re: lvalues (was Re: Question about type casting)
Summary: References.
	 (more provided on request of course ;-)
Message-ID: <2985@killer.UUCP>
Date: 19 Jan 88 18:14:20 GMT
References: <546@xyzzy.UUCP> <5080012@hpfcdc.HP.COM> <10227@mimsy.UUCP> <10236@mimsy.UUCP>
Organization: Big "D" Home for Wayward Hackers
Lines: 85

In article <10236@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> >In article <10227@mimsy.UUCP> I claimed taht
> >>>int i; char *c;
> >>>c = (char *) &i;
> >>>* (int *) c = 0;
> >is not portable, but it is legal.
> 
> In article <2975@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes:
> >I believe it used to be portable.
> 
> It used to be `portable by default': that is, there was no portable
> way to do it at all, but that came closest.
 
Sorry Chris, here's the reference I was refering to in my `I believe'
statement:

	C Language Reference Manual, D. M. Ritchie, 1978

	Section 14.4, paragraph 4

	"A pointer to one type may be converted to a pointer another
	type.  The resulting pointer may cause addressing exceptions
	if the subject pointer does not refer to an object suitably
	aligned in storage.  It is guaranteed that a pointer to an
	object of a given size may be converted to a pointer to an
	object of a smaller size and back again without change."

	[ reprinted without permission ]

Sounds like the closest statement to being portable I can come up
with.

> >Now that X3J11 has mangled the language, it isn't guaranteed to be
> >portable.
> 
> Doug Gwyn mentioned that the current draft makes it portable again.
> (My interpretation of his remark; beware.)

Except that the X3J11 (how close is that to XJ6 or XJS ;-) committee
changed it from `any smaller object' to `may be cast to and from a
void object' (ie, replace (char *) with (void *) ).  This is what I've
read.  I believe the ability to cast to/from a short has been removed.

> >>The result of a cast is an `rvalue' ....
> >>Assignments may be made only to `lvalues' .... The C indirection
> >>operator `*' takes an rvalue and yeilds an lvalue ....
> 
> >Chris, that's some good voodoo.
> 
> ?
> 
> >A cast takes an object of whatever type it happens to be, and whatever
> >state of (l|r)value-ness and changes it's type,
> 
> Good so far.  Note that any lvalue can be converted to an rvalue.
> Note also that the cast may change its bit-pattern and/or shape (e.g.,
> casting short to double).
> 
> >but not it's (l|r)value-ness.
> 
> Whoa!  Stop!  No!  The result of a cast is effectively that of
> assigning to an unnamed temporary variable with the type given
> in the cast.  This is an rvalue.

Yes, you are right.  I deleted the rest of the mess I made.  I misunderstood
you to be saying that `*' somehow turned things into l-values only, which
contradicts being able to dereference a pointer and get an r-value.  The
example was intended to show U-star in both positions.

The best point you [ went on to make ] is that '&' and '*' are complimentary
operations.

> -- 
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
> Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

In-Real-Life:  Captain Fanastic, Defender of Bathroom Soap Scum,

But in this life, I remain -
- John.
-- 
John F. Haugh II                  SNAIL:  HECI Exploration Co. Inc.
UUCP: ...!ihnp4!killer!jfh                11910 Greenville Ave, Suite 600
"Don't Have an Oil Well? ...              Dallas, TX. 75243
 ... Then Buy One!"                       (214) 231-0993 Ext 260