Path: utzoo!attcan!uunet!sdrc!scjones
From: scjones@sdrc.UUCP (Larry Jones)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Another msc 5.1 bug
Message-ID: <489@sdrc.UUCP>
Date: 5 Jan 89 22:40:26 GMT
References: <139@smsdpg.uu.net> <200015@hpmcaa.HP.COM>
Organization: Structural Dynamics Research Corp., Cincinnati
Lines: 37

In article <200015@hpmcaa.HP.COM>, marco@hpmcaa.HP.COM (Marco Dalla-Gasperina) writes:
> / hpmcaa:comp.sys.ibm.pc / seg@smsdpg.uu.net (Scott Garfinkle) / 10:18 am  Jan  3, 1989 /
> I just ran across a neat new (?) bug in MSC5.1:
> you can't use a const pointer to a non-const chunk of memory. 
> ----------
> 
> I'm not sure of this, but I remember that I was having trouble with keeping
> the evaluation order straight in this case...
> 
> int * const a      means the value (*a) is constant 
> int const * a      means the value (a) is constant
> int const * const a means both (a) and (*a) are constant.
> 
> Seems backwards but thats what the manual says!

Well, if that's what the manual says, it's wrong!  (As is the
compiler, apparently.)

Check out the bindings of the declarations (const binds just like
* does):

int * const a <=> int * (const a)
   a is const and thus may not change

int const *a <=> int const (*a) <=> const int (*a)
   *a is const and thus may not change

Since near and far bind differently (perversely to my way of
thinking), it wouldn't be surprising if they erroneously treated
const the same way.

----
Larry Jones                         UUCP: uunet!sdrc!scjones
SDRC                                      scjones@sdrc.uucp
2000 Eastman Dr.                    BIX:  ltl
Milford, OH  45150                  AT&T: (513) 576-2070
"Save the Quayles" - Mark Russell