New section 3.9.6

[Mark Brader]

I recently received the October 1988 Draft Standard.  For the first time,
the copy sent to me had been produced without diff-marks, forcing me to do
a side-by-side comparison with the May Draft to see where there had been
changes.  It was a pleasant exercise, actually, because most of the changes
were simple clarifications and clearly improvements... especially the ones
that I'd suggested...

And then I got to section 3.9.6.

This section is NEW in the October Draft.  It reads as follows:

#    3.9.6  Array parameters
#
#	The use of two parameters declared with an array type (prior
#    to their adjustment to pointer type) in separate lvalues to
#    designate the same object is an obsolescent feature.

[1] What on earth does this section mean in English?

    Well, there is also a new Rationale section to correspond.  It reads:

#	As vector and parallel hardware, and numeric applications in C,
#   become more common, the aliasing semantics of C have been a source
#   of frustration for implementors wanting to make optimum use of such
#   hardware.  If arrays are known not to overlap, certain optimizations
#   become possible, but C currently provides no way to specify to a
#   translator that argument arrays indeed do not overlap.  The Committee,
#   in adopting this future direction, hopes to provide common ground for
#   implementors and users concerned with this problem, so that some
#   future C Standard can adopt this non-overlapping rule on the basis
#   of widespread experience.

    Reading the above tends to confirm my guess as to what the section says.
    I think it is saying that the two currently-equivalent program fragments...

	int f (int *a, int *b)		int f (int a[], int b[])
	{				{
		/* ... */			/* ... */
	}				}

	main()				main()
	{				{
		int x[20];			int x[20];
		f (x, x);			f (x, x);
	}				}

    ... continue to be equivalent *but* that a programmer not wanting to
    use obsolescent features must choose the first syntax rather than
    the second.  So, do I have it right?  (And what if the function f()
    had been in a separate file and the extern declaration had used a
    different syntax from the function definition?)

    If I am right, this change is, well, silly.  To reject on the one hand
    the arguments put forward by me and others about eliminating the
    second syntax (this rejection on the grounds of "long-ingrained
    equivalence"), and then on the other hand to make obsolescent *one
    aspect* of the equivalence, merely gives us the worst of both worlds.

    [I will argue this at greater length later if necessary.]


[2] In any case, whatever it means, the added declaration of something
    as obsolescent MUST BE A SUBSTANTIVE CHANGE unless it was always intended
    to be obsolescent but omitted in error from earlier Drafts.

    The minutes of the September meeting, which I received along with the
    October Draft, say (at page 14):

	Darnell requested (88-146) that we make obsolescent the
	aliasing of array parameters, to leave the door open for
	future semantics.  There was much discussion.

	Straw vote:
		26 make obsolescent aliasing of array parameters
		 7 no
	Accepted.

    I haven't seen the document 88-146 containing the proposal.  But
    there's nothing in the minutes here about whether the much discussion
    included discussion of whether the change was substantive, and no
    indication that it had been intended all along (I'd doubt that).  


[3] So what is going on here?  What it looks like from where I sit is
    an attempt to sneak in a new "noalias" without public review.

    And in view of all the good work that has been done by X3J11 so far,
    this possibility makes me angry.

Mark Brader				"C takes the point of view
SoftQuad Inc., Toronto			 that the programmer is always right"
utzoo!sq!msb, msb at sq.com				-- Michael DeCorte