Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #104363 > unrolled thread

modifying local const variable run time

Back to article view | Back to comp.lang.c

Contents

  modifying local const variable run time rahul.dev.agg@gmail.com - 2017-02-22 06:39 -0800
    Re: modifying local const variable run time GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-22 16:06 +0100
      Re: modifying local const variable run time rahul.dev.agg@gmail.com - 2017-02-22 07:26 -0800
        Re: modifying local const variable run time David Brown <david.brown@hesbynett.no> - 2017-02-22 16:31 +0100
          Re: modifying local const variable run time rahul.dev.agg@gmail.com - 2017-02-22 07:43 -0800
            Re: modifying local const variable run time Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-22 16:06 +0000
        Re: modifying local const variable run time James Kuyper <jameskuyper@verizon.net> - 2017-02-22 11:13 -0500
        Re: modifying local const variable run time supercat@casperkitty.com - 2017-02-22 08:34 -0800
          Re: modifying local const variable run time David Brown <david.brown@hesbynett.no> - 2017-02-22 23:03 +0100
        Re: modifying local const variable run time GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-22 17:34 +0100
          Re: modifying local const variable run time Robert Wessel <robertwessel2@yahoo.com> - 2017-02-22 10:52 -0600
            Re: modifying local const variable run time GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-22 17:52 +0100
              Re: modifying local const variable run time Keith Thompson <kst-u@mib.org> - 2017-02-22 09:33 -0800
              Re: modifying local const variable run time James Kuyper <jameskuyper@verizon.net> - 2017-02-22 15:50 -0500
                Re: modifying local const variable run time supercat@casperkitty.com - 2017-02-22 13:13 -0800
                  Re: modifying local const variable run time Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-22 21:55 +0000
                    Re: modifying local const variable run time supercat@casperkitty.com - 2017-02-22 14:43 -0800
          Re: modifying local const variable run time Keith Thompson <kst-u@mib.org> - 2017-02-22 09:23 -0800
            Re: modifying local const variable run time GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-22 18:32 +0100
              Re: modifying local const variable run time Keith Thompson <kst-u@mib.org> - 2017-02-22 09:50 -0800
                Re: modifying local const variable run time David Brown <david.brown@hesbynett.no> - 2017-02-22 23:07 +0100
                  Re: modifying local const variable run time Keith Thompson <kst-u@mib.org> - 2017-02-22 15:20 -0800
                    Re: modifying local const variable run time David Brown <david.brown@hesbynett.no> - 2017-02-23 09:50 +0100
    Re: modifying local const variable run time James Kuyper <jameskuyper@verizon.net> - 2017-02-22 10:16 -0500
    Re: modifying local const variable run time Keith Thompson <kst-u@mib.org> - 2017-02-22 09:17 -0800

Page 2 of 2 — ← Prev page 1 [2]

#104410

On 22/02/17 18:50, Keith Thompson wrote:
> GOTHIER Nathan <nathan.gothier@gmail.com> writes:
>> On Wed, 22 Feb 2017 09:23:50 -0800
>> Keith Thompson <kst-u@mib.org> wrote:
>>
>>> "const" means read-only.
>>
>> Should we assume that this keyword only provide warnings on assignments with
>> zero optimization?
>
> I'm not sure what that means.  The "const" keyword does not specify
> any kind of optimization.  It imposes constraints on code that code
> that refers to const-qualified objects and types.  A compiler can
> take advantage of those constraints for purposes of optimization,
> but is not required to do so.  In many cases, a compiler can perform
> exactly the same optimizations without the "const" keyword, if it's
> able to infer the same information.
>
> Personally, I use "const" mostly to make code clearer, so it's
> obvious at a glance to a human reader that a given object won't
> be modified, and so that the compiler can diagnose any incorrect
> attempt to modify it.  If a compiler can use that information to
> generate faster code, so much the better.
>

Or more importantly, if the compiler can use that information to spot 
mistakes in the code - accidentally modifying the const object - then so 
much the better.  That's why the "const" keyword is much better than a 
"const" comment would have been, even if the comment were equally 
readable to humans.

[toc] | [prev] | [next] | [standalone]

#104414

David Brown <david.brown@hesbynett.no> writes:
> On 22/02/17 18:50, Keith Thompson wrote:
[...]
>> Personally, I use "const" mostly to make code clearer, so it's
>> obvious at a glance to a human reader that a given object won't
>> be modified, and so that the compiler can diagnose any incorrect
>> attempt to modify it.  If a compiler can use that information to
>> generate faster code, so much the better.
>
> Or more importantly, if the compiler can use that information to spot 
> mistakes in the code - accidentally modifying the const object - then so 
> much the better.  That's why the "const" keyword is much better than a 
> "const" comment would have been, even if the comment were equally 
> readable to humans.

I believe you're repeating part of what I wrote: "... and so that the
compiler can diagnose any incorrect attempt to modify it".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#104464

On 23/02/17 00:20, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 22/02/17 18:50, Keith Thompson wrote:
> [...]
>>> Personally, I use "const" mostly to make code clearer, so it's
>>> obvious at a glance to a human reader that a given object won't
>>> be modified, and so that the compiler can diagnose any incorrect
>>> attempt to modify it.  If a compiler can use that information to
>>> generate faster code, so much the better.
>>
>> Or more importantly, if the compiler can use that information to spot 
>> mistakes in the code - accidentally modifying the const object - then so 
>> much the better.  That's why the "const" keyword is much better than a 
>> "const" comment would have been, even if the comment were equally 
>> readable to humans.
> 
> I believe you're repeating part of what I wrote: "... and so that the
> compiler can diagnose any incorrect attempt to modify it".
> 

So I did - sorry.  (I could claim that I think static error checking is
so important that it is worth repeating it, but I think I just read too
fast late at night.)

[toc] | [prev] | [next] | [standalone]

#104367

On 02/22/2017 09:39 AM, rahul.dev.agg@gmail.com wrote:
> int func(void)
> {
>    const int i = getc();
> 
> }
> 
> Is this correct ? ...

Yes. It is permissible to initialize an object with a const-qualified type.

6.7.9p4 says "All the expressions in an initializer for an object that
has static or thread storage duration shall be constant expressions or
string literals.". getc() is a function call expression, and therefore
does not qualify as a constant expression (6.6p3), but 'i' has automatic
storage duration, so that requirement does not apply. I believe that in
C90, a similar requirement applied to all initializers, but that
requirement was restricted to static storage duration in C99, and
extended to thread storage duration when support for multi-threaded
programs was added in C2011.

> ... Can we modify const local variable run time ?

Any attempt to modify it after it has been initialized is either a
constraint violation or has undefined behavior.
The only operators that allow you to directly modify the value of an
object are the ++, --, simple assignment and compound assignment
operators. For all of those operators, it's a constraint violation if
the relevant operand is not a modifiable lvalue (6.5.2.4p1),
(6.5.3.1p1), 6.5.16p2). "A modifiable lvalue ... does not have a
const-qualified type..." (6.3.2.1p1). So, does this mean you can get
around that restriction by using type punning with an lvalue that isn't
const qualified? No:  "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." (6.7.3p6).
So, are you at least free to modify such objects by using calls to
standard library functions? That's covered too: "If an argument to a
function has an invalid value (such as ... a pointer to non-modifiable
storage when the corresponding parameter is not const-qualified) ... the
behavior is undefined." (7.1.4p1). None of the pointer parameters that
standard library functions write through are const-qualified.

[toc] | [prev] | [next] | [standalone]

#104383

rahul.dev.agg@gmail.com writes:
> int func(void)
> {
>    const int i = getc();
>
> }
>
> Is this correct ?

No, getc() requires an argument of type FILE*.  But if we change it to

    const int i = getc(stdin);

it's perfectly valid (though "i" is a bad name for an object meant to
hold a character read from input; "c" would be better).

>                   Can we modify const local variable run time ?

I think the source of your confusion is the meaning of the keyword
"const".  Though it's obviously derived from the English word
"constant", the words "const" and "constant" mean very different things
in C.

A "constant" is a literal, like 42 or 1.5.  A "constant expression"
is an expression that can (and in many cases must) be evaluated
at compile time, like 2+2.  There are no constants or constant
expressions in your function.

The keyword "const" really means "read-only".  A const-qualified
object is not a constant, it's just an object that you're not
allowed to modify after it's been initialized.  Initializing it
(exactly once) is permitted because it wouldn't be particularly
useful if you couldn't specify a value for it.

Defining an object as "const" doesn't necessarily have any effect on
how it's implemented.  It could be, and in this case very likely is,
stored in memory in exactly the same way that it would be without the
"const".  The only difference is that the compiler will diagnose any
attempts to modify the object, or to store its address in an int*
pointer (which would allow it to be modified via the pointer).

If the initial value is known at compile time, either because it's
a constant expression or because the compiler is able to figure
out what its value must be, then there could be opportunities for
optimization.  The compiler might generate code to store the object
in read-only memory (probably not physical ROM, but memory that's
marked by the OS as read-only when the program is first loaded),
and/or it might not bother to load its value from memory when it's
referred to.  On the other hand, a compiler could do exactly the
same thing with a non-const object if it can prove that it's never
actually modified.

Bottom line: "const" doesn't mean "constant"; "const" means
"read-only".

(There are other programming languages in which the word "constant" has
a different meaning than it has in C.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web