Hi John,

 > Interesting wording.

    Isn't it just? :-)

 > As far as I'm concerned ALL
 > constants are non-volatile.
 > They can be nothing else. If it's volatile it can
 > hardly be thought of as a
 > constant, can it?

    I am inclined that way myself, but I tend to use #define with an
identifier all in upper case as the value of the constant can be changed by
a single change to the source file that way.

 > Beside, I don't read standards. I simply examined run time
 > code. ;-)

    When in doubt I look it up. Also when someone contradicts me - I'm not
infallible. :-)

 > Several things appear to have been overlooked by quite
 > a few participants of
 > this echo. With his knowledge of assembler, Tom in
 > particular *should* have
 > have been considerably less forceful in his
 > assertions. Indeed, he should have
 > a much better understanding of what actually happens
 > when a compiler goes into action.

    Hey ... I'm not into criticising other people, John. I sometimes
criticise code ... when asked. Sometimes I step in if it seems to me that
somebody is being slammed unfairly, but very seldom, because that is
usually up to the moderator.

 > By it's very nature a const is best hard coded within
 > the machine code instructions which comprise the actual run time
 > program.

   On many assemblers, that is true. On others it can be placed in a register.

 > This means of course
 > that no storage space is required to hold the
 > "variable".

   My only contribution to this theme is to say that too damned many people
confuse identifiers with variables.

 > To use variable
 > storage space on something which is not a variable in
 > any real sense is absurd
 > and wasteful of resources. May as well shove a few
 > thousand copies of it on the
 > stack. My sympathies go to anyone unfortunate enough
 > to have a compiler which
 > doesn't understand these things.

    :-) There were a few 8bit machines that couldn't do 'mov mem/reg, imm' type
instructions. The SCMP for one. :-) IIRC that one uses the accumulator for
everything. :-) Yet it had a C compiler and a fortran compiler ...

 > Many people seem to think that the ability to create a
 > pointer to something is
 > "proof" that memory is set aside for it. This is of
 > course nonsense as a
 > pointer merely points to a memory address, real or
 > otherwise. There is no rule
 > to say that such an address must be within an area
 > reserved for variable
 > storage. Indeed, there is nothing to prevent us
 > creating pointers to
 > non-existing memory addresses. I'm sure we've all
 > experienced cases where this
 > has been adequately proven.

    Yup.

 >  BB>     So John is not wrong there. An identifier type-qualified as const
 >  BB> *in C* does NOT require storage space unless its address is used.

 > And not even then. All that is required, as a minimum,
 > is a single instance of
 > the value of the "variable" somewhere within the
 > program's address space.

    But if it is within the address space of the program at a given
location (as you seem to me to imply) then the address of the identifier is
used, and there is no warranty that the contents of the address so used is
empty. In fact there is every likelihood that the address contains the
constant referred to and that thus it *is* occupying storage space (minimal
I agree).

 > And with that I'll say goodbye. Echo
 > disconnected.......

    Come back, John. We can't afford to lose good programmers over trifles.

Best wishes,
Bill.

---