Velocity Reviews > const really constant?

const really constant?

Mantorok Redgormor
Guest
Posts: n/a

 09-19-2003
Is const really constant?

And on an OT note: how can I post with a modified e-mail address so I
don't get so much spam?

Pieter Droogendijk
Guest
Posts: n/a

 09-19-2003
On 19 Sep 2003 13:38:37 -0700
http://www.velocityreviews.com/forums/(E-Mail Removed) (Mantorok Redgormor) wrote:
> Is const really constant?

No, const is a keyword. A variable defined to be const may not change value
after definition.

> And on an OT note: how can I post with a modified e-mail address so I
> don't get so much spam?

--
char*x(c,k,s)char*k,*s;{if(!k)return*s-36?x(0,0,s+1):s;if(s)if(*s)c=10+(c?(x(
c,k,0),x(c,k+=*s-c,s+1),*k)x(*s,k,s+1),0));else c=10;printf(&x(~0,0,k)[c-~-
c+"1"[~c<-c]],c);}main(){x(0,"^[kXc6]dn_eaoh\$%c","-34*1'.+(,03#;+,)/'///*");}

Alex
Guest
Posts: n/a

 09-19-2003
Mantorok Redgormor <(E-Mail Removed)> wrote:
> Is const really constant?

Like Chris Torek always says, 'const' in C means 'read-only'. It
does not act as a constant when a constant expression is expected,
nor does it completely preclude modifications to the variable.

Consider:

const int x = 10;

int array[x]; /* ilegal, not constant expression */

and

const int x = 10;
int *p = (int *)&x;

*p = 2; /* ooops, just changed x */

Alex

Nick Austin
Guest
Posts: n/a

 09-19-2003
On 19 Sep 2003 21:02:05 GMT, Alex <(E-Mail Removed)> wrote:

> const int x = 10;
> int *p = (int *)&x;
>
> *p = 2; /* ooops, just changed x */

Is that not UB?

N869:
"J.2 Undefined behavior

[snip]

-- An attempt is made to modify an object defined with a
const-qualified type through use of an lvalue with non-
const-qualified type."

Nick.

Alex
Guest
Posts: n/a

 09-19-2003
Nick Austin <(E-Mail Removed)> wrote:
> On 19 Sep 2003 21:02:05 GMT, Alex <(E-Mail Removed)> wrote:

>> const int x = 10;
>> int *p = (int *)&x;
>>
>> *p = 2; /* ooops, just changed x */

> Is that not UB?

> N869:
> "J.2 Undefined behavior

> [snip]

> -- An attempt is made to modify an object defined with a
> const-qualified type through use of an lvalue with non-
> const-qualified type."

Looks like you're right. Sorry.

Alex

Ivan Vecerina
Guest
Posts: n/a

 09-19-2003
Hi,
"Alex" <(E-Mail Removed)> wrote in message
news:bkg0dq\$1el38\$(E-Mail Removed)-berlin.de...
> Nick Austin <(E-Mail Removed)> wrote:
> > On 19 Sep 2003 21:02:05 GMT, Alex <(E-Mail Removed)> wrote:

>
> >> const int x = 10;
> >> int *p = (int *)&x;
> >>
> >> *p = 2; /* ooops, just changed x */

>
> > Is that not UB?

>
> > N869:
> > "J.2 Undefined behavior

>
> > [snip]

>
> > -- An attempt is made to modify an object defined with a
> > const-qualified type through use of an lvalue with non-
> > const-qualified type."

>
> Looks like you're right. Sorry.

Yes, however the following is not UB and demonstrates the
same issue:

int f( int* a, int const* b )
{
*a += *b;
return *b; // must re-read *b, may have changed
}

int main()
{
int i = 10;
printf( "%d\n", f(&i,&i) );
return 0;
}

This program must print 20, and the compiler may
not optimize the two accesses to *b within f().
Const guarantees that the value cannot be modified
through the variable/pointer itself. But the
compiler cannot assume that the value will remain
unchanged.

This is why a variable can be both const and volatile.

This is also related to why 'restrict' was introduced
in the C99 standard ...

Kind regards,
Ivan
--
http://ivan.vecerina.com

Peter Nilsson
Guest
Posts: n/a

 09-19-2003
"Nick Austin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 19 Sep 2003 21:02:05 GMT, Alex <(E-Mail Removed)> wrote:
>
> > const int x = 10;
> > int *p = (int *)&x;
> >
> > *p = 2; /* ooops, just changed x */

>
> Is that not UB?
>
> N869:
> "J.2 Undefined behavior
>
> [snip]
>
> -- 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 normative reference is 6.7.3p5

"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. ..."

--
Peter

John L
Guest
Posts: n/a

 09-20-2003

Alex wrote
> Mantorok Redgormor <(E-Mail Removed)> wrote:
> > Is const really constant?

> Consider:
>
> const int x = 10;
>
> int array[x]; /* ilegal, not constant expression */
>
> and
>
> const int x = 10;
> int *p = (int *)&x;

Sorry to digress, but is the cast above necessary? Isn't

int *p = &x;

correct?

Thanks!

Michael Winter
Guest
Posts: n/a

 09-20-2003
> > const int x = 10;
> > int *p = (int *)&x;

>
> Sorry to digress, but is the cast above necessary? Isn't
>
> int *p = &x;
>
> correct?

I believe the reason is that &x will return a pointer that is of type "const
int *". As p doesn't have a const modifier, the assignment will be illegal.
The cast attempts to remove that modifier before assignment. As mentioned
by others, this is undefined in C, but quite legal as I understand (at least
with Microsoft's implementation) in C++.

Mike

--
Michael Winter

Arthur J. O'Dwyer
Guest
Posts: n/a

 09-20-2003

On Sat, 20 Sep 2003, Michael Winter wrote:
>
> > > const int x = 10;
> > > int *p = (int *)&x;

> >
> > Sorry to digress, but is the cast above necessary? Isn't
> > int *p = &x;
> > correct?

>
> I believe the reason is that &x will return a pointer that is of type "const
> int *". As p doesn't have a const modifier, the assignment will be illegal.

That's correct. The address of an 'int' is a pointer to 'int'; the
address of a 'const int' is a pointer to 'const int'.

> The cast attempts to remove that modifier before assignment. As mentioned
> by others, this is undefined in C,

Not quite. The initialization

const int x = 42;
int *p = (int *)&x;

is absolutely legal in C. What's *not* legal is following that
up with

(*p) = 43;

because that tries to modify a const-qualified value. And
since it would be burdensome to make the compiler catch all
such errors, the standard simply calls the result of the
modification "undefined behavior" and leaves it at that.

> but quite legal as I understand (at least
> with Microsoft's implementation) in C++.

I seriously doubt this. My impression is that C++ is *more*
strict about type-safety than C, not less.

-Arthur