Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!ccu!rpjday
From: rpjday@ccu.umanitoba.ca
Newsgroups: comp.std.c
Subject: Re: the "const" qualifier
Message-ID: <1990Aug2.011735.1143@ccu.umanitoba.ca>
Date: 2 Aug 90 01:17:35 GMT
References: <1990Aug1.005200.21645@ccu.umanitoba.ca> <13462@smoke.BRL.MIL>
Organization: University of Manitoba, Winnipeg, Canada
Lines: 85

OK, now that I managed to make a total fool of myself with a well-placed
typo, let me try to prove that I am not a complete cement-head.

In article <13462@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>In article <1990Aug1.005200.21645@ccu.umanitoba.ca> rpjday@ccu.umanitoba.ca writes:

>-  Section 3.5.3, line 26, we have, "For two qualified types to be
>-compatible, both shall have the identically qualified version of a 
>-compatible type..."  Does "compatible" mean assignment compatible?
>
>No, "compatible type" is a technical term defined in section 3.1.2.6.

All right, I can handle that.

>-That is, I am not allowed to do 
>-	const int i = 10;
>-	int j;
>-	j = i;   ???
>-even though this has no effectg on the value of j?
>
>I don't understand your example.  Certainly it is allowed, and the
>value of j is definitely affected (it is set to 10).

Uh, my fault, that should have been "no effect on the value of i".
I realized that, logically, there can be no harm in the above code snippet,
and maybe my confusion is now obvious when I thought "compatible" meant
assignment compatible since, according to the draft, the types
"int" and "const int" are not technically compatible since they are
not identically qualified.  Because of that, I concluded that the
above code, harmless as it was, was somehow illegal.  

>-  This is just the beginning.  At the top of the next page, in the
>-segment of code, line 7 shows an assignment of a const-qualified
>-structure to a non-const-qualified structure.  But based on the
>-previous definition, should this work?  The comment suggests it should.
>
>Of course it should work.  What argumentation would you offer for it
>being disallowed?

See above.  My misunderstanding.

>-  Finally, line 12 of 3.5.3, "If an attempt is made to modify an object
>-defined with a const-qualified type through use of an lvalue with
>-non-const-qualified type, the behavior is undefined."  How would one
>-do this anyway?
>
>	const int j = 10;
>	int *p = (int *)&j;
>	*p = 20;
>
>- Maybe as follows?
>-	const int j = 10 ;
>-	int i ;
>-	*(&i + 1) = 20 ;
>
>Yuck!  That's horrible code, which one has no reason to expect to work.

I wasn't out to win any beauty contests, I just dragged this one out
of the gutter because, in some places, it would do what I wanted --
modify the value of j.

I still, however, have one point of confusion.  On. p. 66, we have
(among other things)

  const struct s { int mem ; } cs = { 1 } ;
  struct s ncs ;
  int *pi;

  pi = &cs.mem;   /* violates type constraints for = */
  ncs = cs ;      /* valid */

Now I can appreciate that the assignment to "pi" should not be allowed,
but PRECISELY which rule makes this illegal?  Is the const qualification
considered part of the "type" so that these are technically different
types and must be cast?  If this is true, I would think that 
the next assignment should be illegal for the same reason (yes,
I know it's totally harmless, but "ncs" and "cs" have different
qualification, so does that make them different types?)

In short, the first assignment should obviously fail, and the second
should obviously work, but what is the rule that makes the first illegal 
and the second valid?  Thanks for the help (and the patience).

R. Day
U of Manitoba