#defines with parameters [was :Re: v05i053: A "safe" ... ]

[Doug Gwyn]

In article <283 at aber-cs.UUCP> pcg at cs.aber.ac.uk (Piercarlo Grandi) writes:
>(and no, I will not even mention my HATE for volatile, far, near and
>the repeated attempts to get noalias in the language, which things in
>my skewed mind overshadow whatever contribution dpANS has made to
>clarify so many other issues).

You really ought to investigate your sources of information!  The dpANS
has never, to my knowledge, proposed that "far" and "near" keywords be
added to C.  In fact they are prohibited in a standard-conforming
implementation.

There have not been "repeated attempts to get noalias in the language".
Since you seem to have missed the excitement, here is a brief summary of
what happened concerning "noalias":
	There were two opposing camps concerning what the meaning of
	the "const" type qualifier should be.  One of them, which
	prevailed when "const" was added to the dpANS, wanted it to
	be compatible with C++ "const", namely to act as a "readonly"
	indicator.  The other camp wanted it to promise something
	about how a so-designated variable could validly be accessed,
	so that optimizers could take advantage of a "const" qualifier
	to provide improved optimation.  In evening working sessions
	preceding preparation of the second formal public review dpANS,
	the opposing camps explored these issues and found that the
	aliasing aspect really could and should be separated from the
	readonly aspect.  Thus, leaving "const" meaning essentially
	"readonly" and introducing a new, orthogonal "noalias" qualifier
	would permit programmers to accurately specify either meaning,
	which was considered a good solution for this issue.  Therefore
	the new "noalias" qualifier (meaning essentially, "this object
	is guaranteed not to be accessed via multiple handles") was
	added for the second formal public review dpANS.

	Unfortunately, the whole area of type qualifiers had not been
	worded quite right in the second formal review draft.  Dennis
	Ritchie in particular complained about the consequent pervasive
	effect that "noalias" would have on library functions, etc.
	This probably could have been fixed up to specify what was
	really intended in the first place, but such a big stink was
	made about addition of a new keyword at such a late date that
	it was not politically possible to salvage it.  As a result,
	the committee withdrew "noalias" between the second and third
	formal public review drafts.  We also have cleaned up the type
	qualifier specification so that it should now reflect the
	committee intention much better than it did in the second round.
	The one sad thing is that there is now no way to make the
	kind of promise that the optimizers needed for non-aliased
	objects.  This reflects existing C practice, but it is
	unfortunate that an improvement in this area wasn't achieved.
So, "noalias" was in the dpANS for ONE draft, it was an attempt to solve
a real performance problem, it would have been transparent to existing
code, and it was promptly removed when the reviewers responded negatively
to it.  That is hardly an evil plot on the part of X3J11.

"volatile" also serves a need.  In fact, it directly addresses one of
the comments I saw earlier today in this newsgroup, about use of C for
accessing device registers.  Again, it is transparent to virtually all
existing code, it addresses a real need, and it can be ignored by anyone
who does not specifically need it.  What is your objection to it?