This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: volatile [was: GCC warnings for unused global variables]


Fergus Henderson <fjh@cs.mu.oz.au> writes:

| On 04-May-2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
| > | On 04-May-2003, Michael Eager <eager@eagercon.com> wrote:
| > | > I don't believe there is any requirement that static variables are
| > | > first set to zero and then set their initial value.
| > | 
| > | C++98 8.5 [dcl.init] paragraph 6: "The memory occupied by any object
| > | of static storage duration shall be zero-initialized at program startup
| > | before any other initialization takes place.".
| > 
| > Which is different from your earlier claim that the *object* is
| > zero-initialized. 
| 
| Are you claiming here a distinction between the object itself and
| the memory (or storage) occupied by the object?

Yes.  The distinction comes into play precisely when you talk about
storage (array of bytes) and the object itself. To understand the
distinction you need to read the *whole* paragraph 1.8/1, not just a
single phrase in isolation.

Suppose, object were equivalent to storage, then you'll have meaningless
phrases like 

3.8/4

  A program may end the lifetime of any storage by reusing the storage
  which the storage occupies or by explicitly calling the destructor
  for a storage of class type with a non-trivial destructor.  For a
  storage of class type with a non-trivial destructor, the program is
  not required to call the destructor explicitly before the storage
  which the storage occupies is reused or released [...]

or

  A program may end the lifetime of any object by reusing the object
  which the object occupies or by explicitly calling the destructor
  for an object of class type with a non-trivial destructor.  For an
  object of class type with a non-trivial destructor, the program is
  not required to call the destructor explicitly before the object
  which the obejct occupies is reused or released [...]

In fact, there are plenty of confused sentences like that, did "object"
equivalent to "storage".

In fact, there is a distinction and when issues like
"value-initialization" was introduced, the committee changed phrases
like

  "The memory occupied by any object"

to

  "Every object"
   

and other places I don't remember off hand.

| According to C++98 1.8 paragraph 1, "An object _is_ a region of storage."
| (my emphasis).  If there is some reason why it is important to make a
| distinction between the two here, I don't see it.
| 
| > | > They can be
| > | > created with the initialized value, if that can be calculated at
| > | > compile time (e.g., if there is no constructor).
| > | 
| > | That is true for non-volatile variables, but only because the compiler
| > | can apply the as-if rule.  As discussed earlier in this thread, the
| > | as-if rule does not apply to volatile variables -- the standard prohibits
| > | implementations from optimizing away accesses to volatile variables.
| > 
| > You keep repeating this false assertion:  Quotes have been to specific
| > text where the standard does actually permit such optimization.
| 
| I'm afraid we'll have to disagree on that point.

You may disagree, but the words of the standard are there.  

| I do not agree that the text which you quoted permitted such optimization.

Still, it says so in black on white.

| I believe you were misinterpreting that text.

The only explanation you gave to support your position was that it was
a parenthentical phrase, but the fact is that whether in parenthesis
or not, a phrase is normative unless part of an example or a note.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]