msb@sq.uucp (Mark Brader) (12/05/88)
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 DeCortehenry@utzoo.uucp (Henry Spencer) (12/06/88)
In article <1988Dec4.161125.20786@sq.uucp> msb@sq.com (Mark Brader) writes: > ... 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? ... Looks right to me. >...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?) I think it's only in the function definition that it matters, but I could be wrong. The probable intent is code optimization, not compile- time checking (which is an intractable problem in the general case anyhow). > 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. Actually, both ideas have the problem of breaking old code. However, note that the new wording does not actually break the equivalence, it merely serves notice that it might break someday. This is different from a proposal which (as I understand it) actually called for immediate breakage. >[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... > >[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. This strikes me as a borderline case, since the added wording does not in fact change the language defined by the standard -- it merely warns of a possible future change. Technically I suspect it would qualify as a substantive change, but I can't get too excited about it. Much of the uproar about noalias was because it was (at least as written -- there's no way to tell what was in the heads of the people involved) thoroughly botched, with slimy tentacles spreading everywhere. A relatively localized and harmless approach would probably have gone through successfully. This seems to me to be much closer to what should have been done originally. I would be unhappy if it had actually been put into the language, but I don't think it's worth a formal protest over a warning of tentative future intent. -- SunOSish, adj: requiring | Henry Spencer at U of Toronto Zoology 32-bit bug numbers. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
karl@haddock.ima.isc.com (Karl Heuer) (12/09/88)
In article <1988Dec5.220907.6239@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <1988Dec4.161125.20786@sq.uucp> msb@sq.com (Mark Brader) writes: >> 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. > >Actually, both ideas have the problem of breaking old code. If the new interpretation were to apply only to prototypes, then no old code would be broken. As Mark and I have repeatedly pointed out, this would have been the perfect opportunity to get rid of one more of K&R's silent rewrite rules. (Note that X3J11 did get rid of the rewrite whereby `f(x) float x; \ {...}' actually declared x as a double; `f(x) int x[]; {...}' is now, I believe, the only such DWIM left in the language.) IMHO, The Committee should have made the entire construct `f(int x[])' obsolescent. This would still allow the Darnell notation$ to be added to a future Standard, if that turns out to be the Right Thing, but it would also allow for more ambitious undertakings%. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint ________ $ The Darnell syntax reserves array notation for pointers to non-overlapping areas, which is apparently what the Committee had in mind when they added this clause. % In particular, the Brader-Heuer syntax, which reserves array notation for (surprise!) arrays, as distinct from pointers.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/09/88)
In article <11126@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >IMHO, The Committee should have made the entire construct `f(int x[])' >obsolescent. This would still allow the Darnell notation$ to be added to a >future Standard, if that turns out to be the Right Thing, but it would also >allow for more ambitious undertakings%. I think the reason there wasn't sufficient support for that more drastic step was that a LOT of correctly-written code exists that uses that notation. Only a small fraction of it would be invalidated were Darnell's semantics to be implemented, but all of it would be invalidated if support for the notation were completely dropped. There are proposals for future addition of array sections etc. to C, but it would be premature to adopt them into the standard before there is sufficient experience with them. I expect several vendors to be working on this as vendor-supported extensions in the next few years.
karl@haddock.ima.isc.com (Karl Heuer) (12/16/88)
In article <9114@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <11126@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes: >>IMHO, The Committee should have made the entire construct `f(int x[])' >>obsolescent. ... > >I think the reason there wasn't sufficient support for that more drastic >step was that a LOT of correctly-written code exists that uses that notation. If you mean code that uses the old-style function definition syntax, I agree; that's why I said it should only apply to prototypes. This substantially reduces the amount of code that would be `broken' (and it wouldn't even be broken, really, if it's flagged as obsolescent but not illegal). >There are proposals for future addition of array sections etc. to C, but >it would be premature to adopt them into the standard before there is >sufficient experience with them. I expect several vendors to be working >on this as vendor-supported extensions in the next few years. I've looked into the possibility of adding array copy% to C, analogous to the way struct copy was added several years ago. In general, the lack of array rvalues is a nuisance but is not fatal; however, the obvious notation for a by-value array parameter is `f(int a[])' -- and this can't be used, if the Standard insists that the compiler must silently rewrite it to `f(int *a)'. It'll be interesting to see what the various vendors use to get around this, when they try to add such array features. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint ________ % By `copy' I mean assignment, pass by value, and return by value.