From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,f0be8eebb2993001
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!feeder.news-service.com!kanaga.switch.ch!news-zh.switch.ch!switch.ch!news.belwue.de!LF.net!news.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Ada 2012 : aliased parameters ?
Date: Sat, 30 Apr 2011 20:32:04 +0200
Message-ID: <87y62ra8uz.fsf@mid.deneb.enyo.de>
References: <op.vs1xo8puule2fv@index.ici> <imriv1$3ti$1@munin.nbi.dk>
	<87aafgerez.fsf@mid.deneb.enyo.de> <ip37ae$n4q$1@munin.nbi.dk>
	<87mxjaf99i.fsf@mid.deneb.enyo.de> <ipcuof$1rn$1@munin.nbi.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: ruchba.enyo.de 1304188324 21467 172.17.135.6 (30 Apr 2011 18:32:04
 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:iYKs5Hgi+r0+k/ull9bU7bcSgDg=
Xref: g2news1.google.com comp.lang.ada:19104
Date: 2011-04-30T20:32:04+02:00
List-Id: <comp.lang.ada>

* Randy Brukardt:

>> This is unfortunate because it means that this cannot be used to make
>> variadic argument list trick safer and less of a hack.
>
> One could argue that variadic arguments are themselves a hack. :-)

It would make it possible to call this little gem, PostgreSQL's main
client function for executing SQL statements,

   PGresult *PQexecParams(PGconn *conn,
                          const char *command,
                          int nParams,
                          const Oid *paramTypes,
                          const char * const *paramValues,
                          const int *paramLengths,
                          const int *paramFormats,
                          int resultFormat);

without any allocations and in a type-safe manner (for a predefined
set of types).  For such untyped external interfaces, varidic
subprograms are often handy.

> The advantage of the aliased parameters is that they eliminate the runtime 
> checks by forcing the checks to the call site (where they can be statically 
> made 99% of the time).

I'm wondering if it is necessary that the returned limited record is
controlled, so that a reference counter can be incremented and later
decremented to ensure that the access discriminant does not become
dangling.  That would make the whole thing a bit clumsy to use, and
come with quite a bit of run-time overhead.

> The intent is that it is impossible to create a dangling pointer if no 
> unchecked programming is used. (Unchecked_Deallocation, 'Unchecked_Access, 
> Unchecked_Conversion, Address_to_Access_Conversions, abuse of 
> Unchecked_Unions, etc.) That goes for all access types (not just anonymous 
> ones). The problem, of course, is that it is impractical to do much without 
> using one of those things. (I've only succeeded in using 'Access once in one 
> of my programs; in all other cases I had to use 'Unchecked_Access.)

Anonymous access types seem to help quite a bit.  I use 'Access for
access discriminants, creating proxies, to fake the in-out parameter
mode for functions, and on locally defined callback functions.

> (Personally, I prefer to hide pointers as much as possible, as in
> the container cursors, so that dangling pointer detection becomes
> much more possible, and their creation becomes less likely.)

And implicit deference could make them even safer to use.