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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a0391eb7e0327d5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-11 05:49:39 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!news.algonet.se!algonet!newsfeed1.uni2.dk!uio.no!newsfeed.song.fi!nntp.inet.fi!central.inet.fi!inet.fi!read3.inet.fi.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Ada style of passing 'in' parameters considered dangerous? From: Antti Sykari Message-ID: <86adh3q6g2.fsf@hoastest1-8c.hoasnet.inet.fi> User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Military Intelligence, i686-pc-linux) References: <86isvuzabx.fsf@hoastest1-8c.hoasnet.inet.fi> <17cd177c.0302110114.2c46b52@posting.google.com> Cancel-Lock: sha1:ur/nLVaOq+T2CxISfA9txB7tfhc= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 13:49:38 GMT NNTP-Posting-Host: 80.221.226.140 X-Complaints-To: abuse@inet.fi X-Trace: read3.inet.fi 1044971378 80.221.226.140 (Tue, 11 Feb 2003 15:49:38 EET) NNTP-Posting-Date: Tue, 11 Feb 2003 15:49:38 EET Organization: Sonera corp Internet services Xref: archiver1.google.com comp.lang.ada:33988 Date: 2003-02-11T13:49:38+00:00 List-Id: gautier_niouzes@hotmail.com (Gautier) writes: >> - If there are such cases, could it have been prevented by having >> different policy in the language? Do you think it would've been >> better to force the programmer to specify the parameter passing >> mechanism, for example? > > Yes and no: the explicit passing mechanism has the advantage of being > ...explicit, but it is not always optimal according to target system. > The "in,in/out,out" is very readable and catches a lot of errors. > The "in", especially, ensures a fast mode and avoiding an explicit > modification. The security problem happens rarely, but it happens. > > I'd suggest that compilers issue a warning when the following > conditions meet: > - there are parameters of the same type, some IN, some [IN] OUT > - the compiler decides to pass the IN by reference > - an IN parameter is referenced after an IN OUT was modified > and also: > - for a call, when the same variable is passed to an IN > by reference and an [IN] OUT (it doesn't solve the issue of > ".all" objects!). I don't think this is enough. For example, you can pass a largish part of a record as an IN OUT parameter (I think you can: I'm not exactly an Ada expert), and the record itself as IN parameter, and modify your IN parameter that way. Or you could call any other subprogram which has access to the record, and modify it that way. In fact, any subprogram call could change it, so it's really impossible to know when to warn. You should be able to guarantee that an IN OUT object is unchanged (unless don't change it directly yourself) and that an IN object is unchanged. One (partial) solution would be restricted types, which guarantee that they are the only means to change the object which they denote. (As with C99's restrict-qualified pointers, which are there primarily to allow optimization and don't change the meaning of a correct program). However, I'm not sure if you can actually trust the compiler to catch all errors even in the presence of such types. In C99, for example, you can still have two restrict-qualified pointers to the same array if you promise not to use them to access the same values. Maybe they would be more useful in a more sophisticated type system (such as Ada's) - or maybe not. A complicated thing. -Antti