'const' keyword problem

[siliconwafer]

Hi All,
Where is an identifier with a 'const' keyword given physical space in
RAM ?
Is it on stack or heap or data segment depending on storage class or is
it treated as a part of code ,so kept in code segment?
What is the case with #define statements?

[Jack Klein]

On 1 Aug 2005 21:19:16 -0700, "siliconwafer" <sp*********@yahoo.com>
wrote in comp.lang.c:

Hi All,
Where is an identifier with a 'const' keyword given physical space in
RAM ?
First, identifiers don't need physical space anywhere, anytime. They
are a source code, compiler, and linker thing. They do not exist at
runtime. Now if the identifier is used to name a defined object, than
that object might or might not need some space somewhere.

Who says it is in RAM at all? On some platforms it will wind up in
ROM or EPROM or some other type of physically read only memory. In
many cases, if its address is never taken and it does not have
external linkage, it will not occupy any memory at all. The compiler
will merely substitute its initial value directly into any code that
uses the value.
Is it on stack or heap or data segment depending on storage class or is
C does not define things like "stack" or "heap" or "data segment". It
defines the characteristics of an abstract machine that has "storage",
without even specifying what that is. In face, in modern
multi-tasking desktop operating systems, it is quite possible that
your const object might be living on a hard drive in a swap file while
some other program is executing and yours is suspended.
it treated as a part of code ,so kept in code segment?
Again, the C language does not specify such details, leaving them up
to the implementation. Your const object, if it occupies storage at
all, is in whatever area of storage the writers of your compiler
decided it should occupy.
What is the case with #define statements?

Macros are handled by the preprocessor, a separate phase of the
compilation process that runs before the compiler proper. It works
primarily by the equivalent of simple text substitution. The compiler
proper never sees the macro identifier, only its replacement.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Chris Torek]

In article <11**********************@g14g2000cwa.googlegroups .com>
siliconwafer <sp*********@yahoo.com> wrote:

Where is an identifier with a 'const' keyword given physical space in
RAM ?
Is it on stack or heap or data segment depending on storage class or is
it treated as a part of code ,so kept in code segment?
Yes, it is on a stack or heap or data segment or kept in the code
segment. Or perhaps in a register. Or maybe written down on one
of the Dead Sea Scrolls. The C standard makes no requirements
beyond those of "behavior observable within a strictly conforming
program".

In practice, most C compilers compile "const T var = value" as if
the "const" qualifier were not present, with a few exceptions:

- If the item would go in read/write space, it *may* go in
read-only space.

- Later occurrences of the named object *may* be replaced with
an in-line expansion of the (presumed) value of the variable,
on the assumption that a correct program cannot change the
value of a "const"-qualified object.

Note, however, that "const" is a type *qualifier*, not a storage
class specifier -- you can write things like "int *const p = &other;"
to make p itself read-only but *p read/write, or "const int *p;"
to make p itself read/write but *p read-only.
What is the case with #define statements?

"#define"d identifiers are expanded textually during phase 4
of compilation, and preprocessor directive lines are not statements.
Hence:

#include <stdio.h>
#include <stdlib.h>

#define HELLO if (
#define THERE {

int main(int argc, char **argv) THERE
HELLO argc < 2 ) THERE
fprintf(stderr, "need arguments\n");
exit(1);
}
printf("thanks.\n");
return 0;
}

is valid (albeit useless and strange) C code. The "#define"d
identifiers are replaced before "compilation proper" (which occurs
in Translation Phase 7).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Flash Gordon]

siliconwafer wrote:

Hi All,
Where is an identifier with a 'const' keyword given physical space in
RAM ?
Is it on stack or heap or data segment depending on storage class or is
it treated as a part of code ,so kept in code segment?
Any, all, or none of those. The compiler can do what it like or even
under some circumstances if it wants completely eliminate it.

There is also no reason for you to nead to know the answer.
What is the case with #define statements?

#defines are textual replacements in the source that occur during
compilation. In some cases there may not be anything to store.
#define FRED int
FRED i;
What has to be stored for FRED? Nothing. Although i requires storage.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Giannis Papadopoulos]

siliconwafer wrote:

Hi All,
Where is an identifier with a 'const' keyword given physical space in
RAM ?
Is it on stack or heap or data segment depending on storage class or is
it treated as a part of code ,so kept in code segment?
What is the case with #define statements?

The answer for the first would be a question:
Where is a const variable stored in system x using compiler y?
--
one's freedom stops where other's begin

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[siliconwafer]

The reason for above question is b'coz I did somthing like this:
const static float c = 5;
.....

c = some expression;

c++;
.....
I used gcc(2.95.1) to compile the above code.It gave me a warning
saying its only a "read only variable".
I neglected the warning and executed the program.
It gave me a *segmentation fault* error and exited.
I thought that the warning is b'coz const object is part of *code
segment * and static objects must be on *data segment*.So there is an
ambiguity as to which segment to refer to.
So what is the reason for *segmentation fault*?

[Giorgos Keramidas]

"siliconwafer" <sp*********@yahoo.com> writes:

The reason for above question is b'coz I did somthing like this: const static float c = 5;

c = some expression;

c++; I used gcc(2.95.1) to compile the above code.It gave me a warning
saying its only a "read only variable".
You should pay great attention to the warnings of the compiler :-)
I neglected the warning and executed the program.
It gave me a *segmentation fault* error and exited.
This is a good reason why.
I thought that the warning is b'coz const object is part of *code
segment * and static objects must be on *data segment*.So there is an
ambiguity as to which segment to refer to.
So what is the reason for *segmentation fault*?

This particular behavior is platform and implementation-dependent.

On some implementations or under particular circumstances, you *may* be
able to modify the value of an object through an identifier declared as
``const''. This is not something you should depend on, though.

[Default User]

siliconwafer wrote:

Hi All,
Where is an identifier with a 'const' keyword given physical space in
RAM ?
Is it on stack or heap or data segment depending on storage class or
is it treated as a part of code ,so kept in code segment?
What is the case with #define statements?

Why to do you care? Is this a quest for abstract knowledge, or are you
trying to do something for which you think this will be important?


Brian

[Jasen Betts]

In article <11**********************@o13g2000cwo.googlegroups .com>, siliconwafer wrote:

The reason for above question is b'coz I did somthing like this:
const static float c = 5;
....

c = some expression;

c++;
....
I used gcc(2.95.1) to compile the above code.It gave me a warning
saying its only a "read only variable".
I neglected the warning and executed the program.
It gave me a *segmentation fault* error and exited.
I thought that the warning is b'coz const object is part of *code
segment * and static objects must be on *data segment*.So there is an
ambiguity as to which segment to refer to.
So what is the reason for *segmentation fault*?

AFAIK gcc for i386 normally produces tiny mode code DS=CS=ES=FS=GS and
pointers are 'near' ie 32 bit offset only

The cuase of the segmentation fault is that the memory page holding the
constant was not writable

Bye.
Jasen

[siliconwafer]

Jasen Betts wrote:

In article <11**********************@o13g2000cwo.googlegroups .com>, siliconwafer wrote:

The reason for above question is b'coz I did somthing like this:
const static float c = 5;
....

c = some expression;

c++;
....
I used gcc(2.95.1) to compile the above code.It gave me a warning
saying its only a "read only variable".
I neglected the warning and executed the program.
It gave me a *segmentation fault* error and exited.
I thought that the warning is b'coz const object is part of *code
segment * and static objects must be on *data segment*.So there is an
ambiguity as to which segment to refer to.
So what is the reason for *segmentation fault*?

AFAIK gcc for i386 normally produces tiny mode code DS=CS=ES=FS=GS and
pointers are 'near' ie 32 bit offset only

The cuase of the segmentation fault is that the memory page holding the
constant was not writable

Bye.
Jasen

Hi once more,

who takes the responsiblity for maintaining the 'const' variable a
'read only' variable?
Is it the compiler ? So when such a variable is mapped to physical
memory location,that location is maintained as 'read only' location
even if its a RAM location.OR being a RAM location,it can be *written*
even if its meant for a const variable or a readf only variable?

sorry for some trouble.
but help required.
Siliconwadfer