const, volatile, etc

[Doug Gwyn]

In article <377 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>[Gwyn thinks:] if you want signed characters, the only way is to add
>a signed keyword, if you want efficient code the only way is a complex
>optimizer that relies on volatile.

You really have not been listening at all, have you?  X3J11 operates
under certain rules and constraints to accomplish a particular task
having particular scope.  "signed" was not invented by X3J11; it
was introduced in several commercial C compilers many years ago as
one way -- the most obvious of several possibilities -- to provide the
C programmer some way to obtain guaranteed signedness for char-sized
objects.  X3J11 had to determine first whether this was a problem in
the base document (K&R 1st Ed. Appendix A) that needed fixing, and if
so, how to fix it.  They agreed with what appears to be your premise,
that this lack in C's integral types needed to be provided in the new
standard.  Then the question became, how best to do that.  In such
cases, whenever there was widespread existing practice, unless it had
some obvious problem it served as a guide for the standard.  In cases
where existing practice was ambiguous (multiple different solutions
had been devised), X3J11 was at liberty to choose one over the other.
The ONLY widespread existing practice for obtaining guaranteed signed
char-sized objects in C was use of the "signed" specifier; since the
only possible technical problem with adopting this (conflict of a new
keyword with existing use as an identifier) was judged to not be
likely to cause much practical problem, it was adopted.  X3J11 could
hardly have done otherwise; ignoring existing practice would run
counter to the committee's charter.

>Again, it has never been a usual rule that an optimizer is allowed to turn a
>correct program into an incorrect one.

The proposed standard is quite specific about the virtual machine
semantics that the C implementation must correctly support.

>But in any case I still must volatilize all other variables, otherwise the
>compiler will do funny things behind my back.

Wrong!!!

>Volatile encourages people to think that a complex optimizer will clean up
>their sloppy C code. Too bad that the cleanup cannot be as good as
>competently written code, ...

You don't seem to appreciate what modern optimization technology can
accomplish.  A good optimizer can significantly speed up well-written
C code.  In fact it often cannot do very much for sloppy code, such
as code that follows your recommendation of declaring all variables
volatile (thereby imposing a constraint that is totally unwarranted
under nearly all circumstances).

>    The use of "volatile" does not require much analysis.  If you were paying
>    attention, I already explained in response to Griff Smith the cases where
>    you need to use it.

>My dear Doug Gwin, rest assured that your paternalistic innuendo is not
>necessary.  I know perfectly well the rationale for "volatile" (enable
>optimizations where side effects may occur); I dispute that the only solution
>to the problem is "volatile", as I dispute the rationale itself.

My name is Gwyn (which as you should know is Welsh), not Gwin!

Again you attempt to put false words in others' mouths.  Please cease
these sleazy debating ploys, as I will not let you get away with them
and I'm sure others are also annoyed by them.

I did NOT say that "volatile" was the only solution to a particular
problem.  However, the solution you suggest (in effect, requiring
what is now known as the volatile attribute for ALL data) is not
acceptable to a large fraction of the current C marketplace.  The
intention is to have a standard that will actually be used, not to
make it unacceptable to a large segment of the C user population.
The determination was made that as high a degree of optimization as
possible should be permitted while remaining consistent with a
reasonable C virtual machine model.  Note that "noalias" arose
out of the insistence of a sufficient number of committee members
on this principle; the attempt to have "pointer to const" function
parameters permit optimization that ignored possible aliasing was
NOT considered reasonable.  We deliberately prohibited the extra,
sometimes quite significant, optimizations that this would have
permitted.  The "optimizer people" on the committee settled for
having explicit programmer use of "noalias" required to permit such
optimization.  ("noalias" has unfortunately been dropped from the
final standard, so this optimization is completely disallowed for
conforming programs compiled by conforming implementations.)  So,
as you should be able to see from this example, X3J11 did NOT wish
to trade off reasonable program semantics for the sake of better
optimization.  The thing you don't seem to agree with is, that we
didn't think that the volatile property should be part of the
reasonable C virtual machine model; in fact quite the contrary --
volatile behavior is quite UNreasaonable, and it is appropriate to
require that the programmer explicitly flag those few instances
where it really is expected.

>I would also like to emphasize that the real big problem will be multi
>threaded C code, not signal handlers or device drivers. As any Ada programmer
>knows, if you use tasking and fail to stick pragmas volatile/shared wherever
>they are needed, maybe in dozens of modules, and that may be a lot of places,
>you get into BIG trouble.

But the C standard does not attempt to define semantics for multitasking
or multiple threads.  This too was deliberate.  If someone (for example,
IEEE 1003) wants to establish additional C constraints for such an
environment, they are free to do so.  For example, it could be required
that the volatile attribute automatically apply to every data object in
such an environment.  However, I guarantee that you have much worse
problems than that to contend with in using any flavor of C in such an
environment.

>    In pre-ANSI C the same problem existed, but there was no standard
>    solution for it.
>The problem did not exist, because it was unthinkable that the compiler would
>do funny things behind your back!

Wrong.  Even Ritchie's PDP-11 C compiler would occasionally do things
when the peephole optimizer was enabled that caused trouble in device
drivers, etc.  This was not generally considered a bug; one merely
revised the code to outwit the optimizer or else turned off the
optimizer.  Many of these problems could have been circumvented through
the use of "volatile", if it had existed.

I explained elsewhere about a horrible kludge that some PCCs had to
selectively disable certain optimizations in a portion of virtual
address space; again "volatile" could have rendered that unnecessary.

>    I would like to be able (maybe in C++ ?) to declare a procedure as
>    "register", to signify that the values it returns only depend on the
>    arguments and not on any globals, and thus it will always return the same
>    values given the same arguments.

This is known as a "pure" function.  It has been suggested before, but
no existing C practice seems to be available to use to judge its merit.

P.S.  It's about time for another reminder that I'm not speaking
officially for X3J11 here, although at least I WAS involved in the
deliberations leading to the final form of the proposed standard,
so there is SOME chance that I'm in a position to appreciate the
trade-offs and decision criteria.