NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/c/12496

Text File | 1992-08-18 | 3.2 KB | 74 lines

Path: sparky!uunet!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
From: [e-mail] (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Paranoia, side effects, and optimizing compilers
Date: 18 Aug 1992 18:47:30 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 61
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <[e-mail]>
[e-mail] ("John E. Davis") writes:
>     unsigned char *p;
>     while (1)
>       {
>          p = CLine->data + Point;
>          if (*p > ' ') break;
>          del();
>       }

Just as a side note, I would probably rewrite this as:

    while (CLine->data[Point] <= ' ')
        del();

>Here CLine->data is a pointer of same type as p and Point is an integer.
>del() is a routine that has that might possibly do a realloc on
>CLine->data so p might change in the loop.

>Would an optimizing compiler asssume that p will not change in the loop,
>evaluate it once and assume it is fixed in the loop?  [or should I make
>p `volatile']

Short answer: if so, it would be broken.

In article <[e-mail]> [e-mail] (Larry Meadows) gets
this right.  He goes on to say that

>volatile is only necessary for variables that might change due to events
>that aren't explicitly specified (e.g., shared memory multiprocessor
>systems, setjmp-longjmp, interrupt handlers, external hardware).

More precisely, those that might change *or be accessed*: compilers
can move or eliminate assignments to nonvolatile variables, provided
this is not detectable through proper C language constructs.  Volatile
variables are (aside from longjmp and signals, where the standard wimps
out :-) ) those that are used in some way ``outside'' the language.
This includes things like programs or hardware that scan shared memory,
as well as those that change them.

In article <[e-mail]> [e-mail]
(Stephen Baillie) writes:
>Strangely enough, it depends on the compiler.  For example, Microsoft's
>C/C++ 7 gives one two options on this - /Oa to assume that there is no
>aliasing (function calls do not change variables) and /Ow for weak
>aliasing (function calls may change variables, but things in the code don't)

These options are nonconformant.  Microsoft has chosen to give you
several ways to say: ``compile a language that resembles C, but is not
actually C'', because programs written in those other languages are
easier to compile.  As a result, if you write programs in those other
languages---whether deliberately or accidentally---Micosoft's not-
quite-C version of the compiler may produce faster object code.

(Whether these `weakened' version of C are a Good Thing depends on
one's point of view.  It is far easier to get in trouble with them; but
on the other hand, it is far easier to write a compiler that produces
faster code with them.)
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE ([phone])
Berkeley, CA        Domain:    [e-mail]