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 1 of 2  [1] 2  Next page →

#104363 — modifying local const variable run time

int func(void)
{
   const int i = getc();

}

Is this correct ? Can we modify const local variable run time ?

[toc] | [next] | [standalone]

#104365

On Wed, 22 Feb 2017 06:39:51 -0800 (PST)
rahul.dev.agg@gmail.com wrote:

> int func(void)
> {
>    const int i = getc();
> 
> }
> 
> Is this correct ? Can we modify const local variable run time ?

It should be correct if you don't try to assign a value to your constant
integer. Constant objects should only be initialized.

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

#104368

On Wednesday, February 22, 2017 at 8:38:13 PM UTC+5:30, GOTHIER Nathan wrote:
> On Wed, 22 Feb 2017 06:39:51 -0800 (PST)
> rahul.dev.agg@gmail.com wrote:
> 
> > int func(void)
> > {
> >    const int i = getc();
> > 
> > }
> > 
> > Is this correct ? Can we modify const local variable run time ?
> 
> It should be correct if you don't try to assign a value to your constant
> integer. Constant objects should only be initialized.

But, how this would be implemented ?
I read that const variable can be stored in read only memory.
In that case, it's value should be known at compile time.
Or is there I am missing something ?

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

#104370

On 22/02/17 16:26, rahul.dev.agg@gmail.com wrote:
> On Wednesday, February 22, 2017 at 8:38:13 PM UTC+5:30, GOTHIER Nathan wrote:
>> On Wed, 22 Feb 2017 06:39:51 -0800 (PST)
>> rahul.dev.agg@gmail.com wrote:
>>
>>> int func(void)
>>> {
>>>    const int i = getc();
>>>
>>> }
>>>
>>> Is this correct ? Can we modify const local variable run time ?
>>
>> It should be correct if you don't try to assign a value to your constant
>> integer. Constant objects should only be initialized.
> 
> But, how this would be implemented ?
> I read that const variable can be stored in read only memory.
> In that case, it's value should be known at compile time.
> Or is there I am missing something ?
> 

A compiler /may/ put a const object in read-only memory, if it knows the
initialisation value when the program is compiled.  It can't do that for
const objects that are initialised at run time.  Think of your code here
as a saying "I want an "int" called "i", initialised to the result of a
call to getc(), and it will not be changed after initialisation".

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

#104372

On Wednesday, February 22, 2017 at 9:01:28 PM UTC+5:30, David Brown wrote:
> On 22/02/17 16:26, rahul.dev.agg@gmail.com wrote:
> > On Wednesday, February 22, 2017 at 8:38:13 PM UTC+5:30, GOTHIER Nathan wrote:
> >> On Wed, 22 Feb 2017 06:39:51 -0800 (PST)
> >> rahul.dev.agg@gmail.com wrote:
> >>
> >>> int func(void)
> >>> {
> >>>    const int i = getc();
> >>>
> >>> }
> >>>
> >>> Is this correct ? Can we modify const local variable run time ?
> >>
> >> It should be correct if you don't try to assign a value to your constant
> >> integer. Constant objects should only be initialized.
> > 
> > But, how this would be implemented ?
> > I read that const variable can be stored in read only memory.
> > In that case, it's value should be known at compile time.
> > Or is there I am missing something ?
> > 
> 
> A compiler /may/ put a const object in read-only memory, if it knows the
> initialisation value when the program is compiled.  It can't do that for
> const objects that are initialised at run time.  Think of your code here
> as a saying "I want an "int" called "i", initialised to the result of a
> call to getc(), and it will not be changed after initialisation".

ok. Great !!!  Thanks.

Just curious how this will be implemented ?

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

#104374

rahul.dev.agg@gmail.com writes:

> On Wednesday, February 22, 2017 at 9:01:28 PM UTC+5:30, David Brown wrote:
>> On 22/02/17 16:26, rahul.dev.agg@gmail.com wrote:
>> > On Wednesday, February 22, 2017 at 8:38:13 PM UTC+5:30, GOTHIER Nathan wrote:
>> >> On Wed, 22 Feb 2017 06:39:51 -0800 (PST)
>> >> rahul.dev.agg@gmail.com wrote:
>> >>
>> >>> int func(void)
>> >>> {
>> >>>    const int i = getc();
>> >>> }
>> >>>
>> >>> Is this correct ? Can we modify const local variable run time ?
>> >>
>> >> It should be correct if you don't try to assign a value to your constant
>> >> integer. Constant objects should only be initialized.
>> > 
>> > But, how this would be implemented ?
>> > I read that const variable can be stored in read only memory.
>> > In that case, it's value should be known at compile time.
>> > Or is there I am missing something ?
>> 
>> A compiler /may/ put a const object in read-only memory, if it knows the
>> initialisation value when the program is compiled.  It can't do that for
>> const objects that are initialised at run time.  Think of your code here
>> as a saying "I want an "int" called "i", initialised to the result of a
>> call to getc(), and it will not be changed after initialisation".
>
> ok. Great !!!  Thanks.
>
> Just curious how this will be implemented ?

The only thing a compiler must do is to report certain cases where i is
used inappropriately.  The compiler has to remember that i is const
(just like it must remember that i is an int) so that if, in the same
scope, it sees i++ or i = 99 is can report it.  It does not even have to
stop compiling the code.  It can generate code to do the operation as if
i were not const.  It can refuse to generate a runable binary or it can
do pretty much anything at all since the code now has undefined
behaviour.

C has no way to stop the programmer from modifying an object.  Using
const just provides some help in preventing unintended modifications and
it can make the code easier to understand by removing one less thing to
think about.

-- 
Ben.

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

#104375

On 02/22/2017 10:26 AM, rahul.dev.agg@gmail.com wrote:
> On Wednesday, February 22, 2017 at 8:38:13 PM UTC+5:30, GOTHIER Nathan wrote:
>> On Wed, 22 Feb 2017 06:39:51 -0800 (PST)
>> rahul.dev.agg@gmail.com wrote:
>>
>>> int func(void)
>>> {
>>>    const int i = getc();
>>>
>>> }
>>>
>>> Is this correct ? Can we modify const local variable run time ?
>>
>> It should be correct if you don't try to assign a value to your constant
>> integer. Constant objects should only be initialized.
> 
> But, how this would be implemented ?
> I read that const variable can be stored in read only memory.
> In that case, it's value should be known at compile time.
> Or is there I am missing something ?

I've heard of systems where arbitrary blocks of memory can be changed
from read/write to read-only or vice-versa by use of an appropriate
operating system function. I know none of the details about what systems
those are, or how it works. On such a system, a conforming
implementation of C could generate a program that moves 'i' into
read-only memory after initializing it, and then makes the memory
writable again after the lifetime of that object has ended.

Keep in mind that use of read-only memory is merely permitted by the
rules that govern 'const', it's not mandatory. The most important fact
about defining a const-qualified objects is that an implementation is
allowed to optimize your code based upon the assumption that the value
stored in such an object will never change. As a result, if your code
actually attempts to change that value, the optimization is permitted to
have unexpected consequences. The most plausible possibilities is that
the change you make won't actually occur (the implementation is
permitted to simply remove such code), or that it won't be noticed
immediately. The program could retrieve the current value, and save it
in a register, and keep using the value in the register even after the
value in memory has changed. It might do another read from memory at an
unpredictable later time, rather than immediately after the change. Even
more confusing, different expressions in the same piece of code might
refer either to the value in memory or the value in the register. More
complicated and disastrous possibilities almost certainly exist, but I
can't think of any right now.

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

#104377

On Wednesday, February 22, 2017 at 9:26:55 AM UTC-6, rahul....@gmail.com wrote:
> I read that const variable can be stored in read only memory.
> In that case, it's value should be known at compile time.
> Or is there I am missing something ?

Very rarely will a compiler physically place anything into read-only memory
(or any kind of memory, for that matter) for direct use by a program.  It's
much more common for a compiler to generate a file whose contents will be
placed in memory by something else.  If a compiler is intended for use with
embedded-systems projects, it should generally support at least two ways in
which any expectations it has about "constants" may prove correct, though
the first could be supported (with some loss of efficiency) merely be
supporting the second.  In particular:

1. Between the time the compiler generates its output and the time the code
   starts execution, some other process might alter the contents of the
   file.  For example, if code does:

    #pragma psect=VERSION
    const char version_number[]="$$VERSION$$";

   the link script might specify that section VERSION must be placed at a
   certain address, and a later part of the build process might check that
   the string "$$VERSION$$" appears at that address and plug in an auto-
   generated version number.  Depending upon how the compiler defines its
   psect #pragma, that directive may be sufficient to prevent the compiler
   from making any assumptions about the initial contents of the storage.

2. Some systems may have memory which *usually* behaves in read-only
   fashion, but whose contents may be changed under program control.  For
   example, if a system uses two 28C64 EEPROM chips for code storage at
   addresses 0xC000-0xDFFF and 0xE000-0xFFFF, a write to an address in
   one of those ranges would trigger a write cycle during which any attempt
   to read anything from the chip would yield bogus data.  If code knew
   that some variable "foo" was at an aligned address within one of those
   chips, it could change that value using the following code if it could
   ensure that nothing else would access that same chip until the update
   procedure finished.

   // The following variable must not cross 64-byte boundary!
   extern const volatile uint32_t myvariable;

   *(uint32_t volatile*)&myvariable = 0x12345678;
   do {} while(*(uint32_t volatile*)myvariable != 0x12345678);

   Hardware in the memory chip would guarantee that no byte read back
   from the chip would match the last byte written until the write cycle
   had completed (whereupon reads would start reporting the contents of
   the addressed memory).

Note that if code were to write myVariable without taking care to wait for
the write to complete, that could totally disrupt system behavior, thus
making a "const" qualifier generally useful.  The use of volatile qualifiers
within the write-and-wait code should allow a quality embedded-system
compiler to yield correct code without having to mark the variable "volatile",
and omitting the qualifier would allow a quality compiler to generate more
efficient code, but including the qualifier on the variable would be safer.

Note that any quality embedded-systems compiler should be expected to handle
correctly any situation where a volatile-qualified write to one address
changes the contents of "const volatile" variables stored any other
arbitrary addresses.  There's no reason why such a compiler should assume
that such a write would not be capable of changing a "const volatile" object
at the address that was written if the hardware would support such behavior.

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

#104407

On 22/02/17 17:34, supercat@casperkitty.com wrote:
> On Wednesday, February 22, 2017 at 9:26:55 AM UTC-6, rahul....@gmail.com wrote:
>> I read that const variable can be stored in read only memory.
>> In that case, it's value should be known at compile time.
>> Or is there I am missing something ?
>
> Very rarely will a compiler physically place anything into read-only memory
> (or any kind of memory, for that matter) for direct use by a program.  It's
<snip>

In what way do you this this rambling collection of run-on sentences 
will help the OP understand what he is asking about?

It's little wonder some people feel this newsgroup is too scary for newbies.

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

#104378

On Wed, 22 Feb 2017 07:26:47 -0800 (PST)
rahul.dev.agg@gmail.com wrote:

> But, how this would be implemented ?
> I read that const variable can be stored in read only memory.
> In that case, it's value should be known at compile time.
> Or is there I am missing something ?

I'm not an assembly expert but from my understanding the "const" keyword
indicates to the compiler that the object shouldn't be POP from the stack, thus
limiting moves in register. This is an optimization to keep write enabled
objects on the top of the stack.

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

#104380

On Wed, 22 Feb 2017 17:34:50 +0100, GOTHIER Nathan
<nathan.gothier@gmail.com> wrote:

>On Wed, 22 Feb 2017 07:26:47 -0800 (PST)
>rahul.dev.agg@gmail.com wrote:
>
>> But, how this would be implemented ?
>> I read that const variable can be stored in read only memory.
>> In that case, it's value should be known at compile time.
>> Or is there I am missing something ?
>
>I'm not an assembly expert but from my understanding the "const" keyword
>indicates to the compiler that the object shouldn't be POP from the stack, thus
>limiting moves in register. This is an optimization to keep write enabled
>objects on the top of the stack.


No, it does nothing of the sort.

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

#104381

On Wed, 22 Feb 2017 10:52:32 -0600
Robert Wessel <robertwessel2@yahoo.com> wrote:

> No, it does nothing of the sort.

Tell more about what it does...

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

#104388

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Wed, 22 Feb 2017 10:52:32 -0600
> Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>> No, it does nothing of the sort.
>
> Tell more about what it does...

I already did.  Read my other followup in this thread.

-- 
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]

#104399

On 02/22/2017 11:52 AM, GOTHIER Nathan wrote:
> On Wed, 22 Feb 2017 10:52:32 -0600
> Robert Wessel <robertwessel2@yahoo.com> wrote:
> 
>> No, it does nothing of the sort.
> 
> Tell more about what it does...
> 

The primary effect of correctly used 'const' is that it allows you to
tell the implementation that something should not be modified, and it
requires the implementation to warn you if you write certain kinds of
code that puts something so-marked at risk of being modified. The
implementation is free to reject any program containing such code. If it
chooses not to reject it, and if you choose to attempt execution of the
resulting program, the behavior is undefined.

The second effect occurs only when const applies to the definition of an
object. It makes it undefined behavior to make any attempt to modify the
value of that object.  "undefined behavior" doesn't impose any
requirements on the implementation - quite the opposite: it means that
the standard imposes no requirements on the behavior. This permits the
object being loaded into read-only memory, among other possibilities.
However, how an implementation takes advantage of this fact is entirely
up to the implementation.

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

#104402

On Wednesday, February 22, 2017 at 2:50:27 PM UTC-6, James Kuyper wrote:
> The second effect occurs only when const applies to the definition of an
> object. It makes it undefined behavior to make any attempt to modify the
> value of that object.  "undefined behavior" doesn't impose any
> requirements on the implementation - quite the opposite: it means that
> the standard imposes no requirements on the behavior. This permits the
> object being loaded into read-only memory, among other possibilities.
> However, how an implementation takes advantage of this fact is entirely
> up to the implementation.

There is another case where "const" is relevant: if a block starts with a
declaration like

   void const * const restrict arbitraryName = &something;

a compiler would be entitled to assume that the object in question will
not be modified by any means during the execution of that block, even if
the object in question is not const-qualified and might perfectly
legitimately be modified *at times when the block isn't being executed*.
That may facilitate optimizations that would not otherwise be possible,
though it would seem like a directive that was equivalent to such a
construct but didn't require defining a dummy variable might be clearer.

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

#104404

supercat@casperkitty.com writes:
<snip>
> There is another case where "const" is relevant: if a block starts with a
> declaration like
>
>    void const * const restrict arbitraryName = &something;
>
> a compiler would be entitled to assume that the object in question will
> not be modified by any means during the execution of that block, even if
> the object in question is not const-qualified and might perfectly
> legitimately be modified *at times when the block isn't being executed*.
> That may facilitate optimizations that would not otherwise be possible,
> though it would seem like a directive that was equivalent to such a
> construct but didn't require defining a dummy variable might be
> clearer.

Is this an example of undefined behaviour you are describing:

  int main(void)
  {
      int something = 1;
      void const * const restrict arbitraryName = &something;
      something = 0;
      return something;
  }

If so, can you say why it's undefined?  I can see only one lvalue being
used (something) and a pointer to it (&something) is not an expression
based on arbitraryName.  Have I misunderstood?

-- 
Ben.

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

#104412

On Wednesday, February 22, 2017 at 3:55:14 PM UTC-6, Ben Bacarisse wrote:
> Is this an example of undefined behaviour you are describing:
> 
>   int main(void)
>   {
>       int something = 1;
>       void const * const restrict arbitraryName = &something;
>       something = 0;
>       return something;
>   }
> 
> If so, can you say why it's undefined?  I can see only one lvalue being
> used (something) and a pointer to it (&something) is not an expression
> based on arbitraryName.  Have I misunderstood?

I forgot to add a dummy access via the pointer, but N1570 6.7.3.1 [Formal
definition of restrict] paragraph 4 specifies that if an object is accessed
via a restrict qualified pointer or any pointer derived therefrom and is
modified by any means, the restrict-qualified pointer most not also be
const-qualified; violation of that restriction invokes UB.

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

#104386

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Wed, 22 Feb 2017 07:26:47 -0800 (PST)
> rahul.dev.agg@gmail.com wrote:
>> But, how this would be implemented ?
>> I read that const variable can be stored in read only memory.
>> In that case, it's value should be known at compile time.
>> Or is there I am missing something ?
>
> I'm not an assembly expert but from my understanding the "const"
> keyword indicates to the compiler that the object shouldn't be POP
> from the stack, thus limiting moves in register. This is an
> optimization to keep write enabled objects on the top of the stack.

No, that's not what "const" means at all.  And being an assembly expert
wouldn't help, since it's a C keyword.

"const" means read-only.

-- 
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]

#104389

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? This reminds me the dumb programmer using annex K in C11 for
his safety...

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

#104390

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.

-- 
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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web