Checksum: 47415 Lines: 92 Path: utzoo!sq!msb From: msb@sq.uucp (Mark Brader) Date: Sun, 4-Dec-88 16:11:25 EST Message-ID: <1988Dec4.161125.20786@sq.uucp> Newsgroups: comp.std.c Subject: New section 3.9.6 Summary: 3.9.6 must go? Reply-To: msb@sq.com (Mark Brader) Organization: SoftQuad Inc., Toronto 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@sq.com -- Michael DeCorte