From maine@altair.dfrf.nasa.gov Thu Feb 16 19:05:45 1995 Received: from altair.dfrf.nasa.gov by dkuug.dk with SMTP id AA15964 (5.65c8/IDA-1.4.4j for ); Thu, 16 Feb 1995 20:52:27 +0100 Received: by altair.dfrf.nasa.gov (5.0/SMI-SVR4) id AA03485; Thu, 16 Feb 1995 11:05:45 +0800 Date: Thu, 16 Feb 1995 11:05:45 +0800 From: maine@altair.dfrf.nasa.gov (Richard Maine) Message-Id: <9502161905.AA03485@altair.dfrf.nasa.gov> To: SC22WG5@dkuug.dk In-Reply-To: <199502161659.AA12134@dkuug.dk> (jkr@letterbox.rl.ac.uk) Subject: Re: (SC22WG5.711) Re: defect item 173 Content-Length: 0 X-Charset: ASCII X-Char-Esc: 29 On Thu, 16 Feb 95 16:57:11 GMT, jkr@letterbox.rl.ac.uk (John Reid) said: John> No. Suppose we have: John> INTEGER, TARGET :: FROM(2) John> INTEGER, POINTER :: TO(:) John> : John> TO => FROM(2:1:-1) John> CALL MVBITS(FROM,1,10,TO,1) John> We need to disallow this, but FROM and TO are not storage associated. John> FROM occupies 2 adjacent integer storage units. TO occupies a single John> unspecified storage unit that is different from that of any John> nonpointer object [247:39-40]. I believe that it is the target pointed to by "TO" that is passed as the actual argument, not "TO" itself. Thus the unspecified storage unit stuff doesn't apply. That is only for when the pointer itself is under consideration (as when there is a pointer component of a derived type or there is a pointer in COMMON). I haven't though enough about the other aspects of the issue to comment usefully at the moment (and I'm too busy working on the 007 to do so), but this comment occurred to me right away. -- Richard Maine maine@altair.dfrf.nasa.gov