New section 3.9.6

[Karl Heuer]

In article <9114 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <11126 at haddock.ima.isc.com> karl at 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 at haddock.isc.com), The Walking Lint
________
% By `copy' I mean assignment, pass by value, and return by value.