Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Const values not stored in .text section Date: Wed, 29 Mar 2017 09:55:25 -0700 Organization: None to speak of Lines: 92 Message-ID: References: <391e9782-09dd-43a6-a279-e9b72d6c2cd2@googlegroups.com> <69dbb499-1893-464b-8d25-7193e1796285@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="91354899e69b8a2f4977e8b6ca3f6948"; logging-data="5309"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+G6MAmkG2G3P5RDHiBUEao" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:o4wRMVtvYoLRKibHIDOxJ4y8I4E= sha1:YvSQsQ50EAWI1x7WFLFkX4YnDXA= Xref: csiph.com comp.lang.c:107407 acidlategamer@gmail.com writes: [...] > I made this change I've taken the liberty of fixing your code's indentation. > #include > const int a = 32; This defines an object named "a". It has type int, and its initial value is 32. It has static storage duration, meaning that it exists for the entire lifetime of the program. The "const" means that any attempt to assign to it directly is a constraint violation, and any attempt to modify its value indirectly has undefined behavior. > int main() A very minor point: this should be "int main(void)". > { > int *p; > p = &a; &a is of type "const int*". p is of type "int*". Assigning an int* value to a const int* object is a constraint violation. You probably got a non-fatal warning, but your compiler could have treated it as a fatal error (and if you had compiled with "gcc -pedantic-errors", it would have). Saying that something is a "constraint violation" is about as close as C comes to saying that something is illegal. So don't do that. > *p = 45; If the compiler hasn't already rejected your program, this has undefined behavior, because you're trying to modify a const-qualified object. > printf("%d %p\n", a, (void *)&a); > return 0; > } > output : segmentation fault > > What happens in this case? Now where should be the variable stored now? > So I deduce this in my compiler case It doesn't really where it's stored. The C standard says nothing about text sections. It specifies the lifetime of storage. > 1. If a variable is const and is a global value, then it will be > stored on text section. Any object defined at file scope (outside any function definition) *or* with the "static" keyword has static storage duration, meaning that it exists (at least logically) during the entire execution of the program. The "const" keyword doesn't affect this, it merely means that you can't legally modify it. > 2. If a variable is a const and a local variable, compiler will do > what it think is best place to store. An object defined within a function definition without the "static" keyword has automatic storage duration, meaning that it exists (is created and then deallocated) only during the execution of the enclosing block. Again, the "const" keyword doesn't affect this. Compilers can and often do perform optimizations that change how and whether objects are stored. For example, if you write const int n = 42; at block scope, and never take the address of n, then a compiler might choose not to allocate storage for n, and to replace every reference to n with a constant value of 42. It can do the same thing without the "const" if it can prove that n is never modified. As for "global" objects, things like the "text segment" and "bss segment" are implementation details, not mentioned by the language standard. You can probably find out how particular objects are stored by examining an assembly listing, and that might be affected by the presence of absence of "const" and/or an initialization. But don't assume that any such information applies beyond the particular implementation you're using. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"