Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news1.tnib.de!feed.news.tnib.de!news.tnib.de!fu-berlin.de!uni-berlin.de!news.dfncis.de!not-for-mail From: =?ISO-8859-1?Q?Hans-Bernhard_Br=F6ker?= Newsgroups: comp.std.c Subject: Re: Initial draft proposal: "Safe arrays and pointers for C" Date: Mon, 20 Aug 2012 22:40:51 +0200 Lines: 78 Message-ID: References: <502949DA.9000604@animats.com> <502E94CB.1000103@loria.fr> <502ECEB9.3060407@loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.dfncis.de ahXq7l9TF1EmWmwPrLYYvgib65jyUUCVFPjFyZurRGYi+rxYb2+Eben8zLJTV0MgVuOheStZoH Cancel-Lock: sha1:WYS8UQR1Tl42tTODYEHVssWO+E8= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120604 Thunderbird/13.0 In-Reply-To: Xref: csiph.com comp.std.c:1571 On 20.08.2012 08:14, John Nagle wrote: > What semantics could we give VLA parameters that would > keep all the size information around but not break anything > important? None, because there _are_ no VLA parameters. What you need is new _syntax_ to actually introduce array parameters to the language in the first place. Then you can start thinking about semantics. > Worse, how can fixed-length arrays be given similar semantics. You're still chasing the red herring. Forget about VLAs for the moment. They may come up at some point down the road, but right now, they're only distracting you. > One option is to distinguish between fully-dimensioned arrays > and arrays where some dimension is unspecified. No, that is not an option. Not unless you're looking for way to sabotage your own proposal, that is. There is essentially no way you'll be allowed to introduce new meaning to existing syntax that has meant the same thing for over 20 years. > The unspecified case is a classic pointer. The > fully specified case could potentially be handled > differently. That potential is effectively identical to zero. Forget it. > The way this ought to work is that, in this > example > > void fn4(int a1[100]) > { int a2[100]; > } > > a1 and a2 should have similar semantics. They > don't. Exactly. And you will not change that. No way. You will not break a sizable portion of all existing C code for this. So please do everybody including yourself a favour and stop thinking in that direction --- you would only be wasting your time. > a1++; // error, not a lhs Wrong. Allowed. > a2++; // allowed Wrong. Error, not a lhs. > sizeof(a1); // equals sizeof int Wrong. That equals sizeof(int *) > How about this? > > 1. Support the "pass by reference" described in the paper. > Example: > void fn5(int (&a1)[100]); There's no particularly strong need for that. We already have a perfectly usable void fn5(int (*a1)[100]); "Pass by reference" has meant "pass by pointer" since the beginning of C. Reference arguments (the ones with a &) are really just syntactic sugar on top of that. For the purposes of your proposal, they're not really much more than another distraction off the actual issue. And I for one am rather less than convinced that this reference syntax is a good candidate for the new syntax you'll need for actually passing arrays into a C --- because that syntax already means something else in C++, where it has a much broader use.