RE: [sv-bc] "Assignment ... to a constant expression"

I thought this assignment is illegal on the grounds that it is
recursively accessing the value of c in its definition.

Dave


> -----Original Message-----
> From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
On
> Behalf Of Bresticker, Shalom
> Sent: Friday, April 25, 2008 7:28 AM
> To: sv-bc
> Subject: RE: [sv-bc] "Assignment ... to a constant expression"
> 
> By the way, I just found the following example in 6.19.5.7:
> 
> typedef enum { red, green, blue, yellow } Colors;
> Colors c = c.first;
> 
> This indicates that the 'point of declaration' is before the
> initializing expression (as I would personally would expect).
> 
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org
> > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom
> > Sent: Thursday, April 24, 2008 11:58 AM
> > To: Greg Jaxon; Brad Pierce
> > Cc: sv-bc@server.eda.org
> > Subject: RE: [sv-bc] "Assignment ... to a constant expression"
> >
> > Do you mean for a statement like
> >
> > integer r = r + 1 ; ?
> >
> > I think these are two separate issues. Gord brought up your
> > issue some time ago. I did not yet find where.
> >
> > Here we are just making the LRM consistent.
> >
> > The issue could come up also in a parameter declaration, I think.
> >
> > Even if one would be allowed to do such a thing, I would not
> > want to encourage. It seems to me to be bad methodology to
> > use the same identifier with two different meanings.
> >
> > Shalom
> >
> >
> > > One item that isn't crystal clear and arises as soon as the
> > "constant
> > > expression" requirement is dropped is where the "point of
> > declaration"
> > > for the variable lies, before, or after, the initializing
> > expression?
> > > If that's not clear enough elsewhere, it should be stated
> > in place of
> > > the "constant expression" restriction.
> >
---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential
> > material for the sole use of the intended recipient(s). Any
> > review or distribution by others is strictly prohibited. If
> > you are not the intended recipient, please contact the sender
> > and delete all copies.
> >
> >
> > --
> > This message has been scanned for viruses and dangerous
> > content by MailScanner, and is believed to be clean.
> >
> >
> >
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.