🚀 go-pugleaf

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.