From Keith.Bierman@Eng.Sun.COM Mon Jan 29 20:25:08 1996 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA16258 for ; Mon, 29 Jan 1996 20:25:03 +0100 From: Keith.Bierman@Eng.Sun.COM Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id LAA19457; Mon, 29 Jan 1996 11:24:14 -0800 Received: from chiba.eng.sun.com by Eng.Sun.COM (5.x/SMI-5.3) id AA13277; Mon, 29 Jan 1996 11:24:07 -0800 Received: from localhost by chiba.eng.sun.com (4.1/SMI-4.1) id AA14033; Mon, 29 Jan 96 11:24:03 PST Message-Id: <9601291924.AA14033@chiba.eng.sun.com> To: Craig Dedo Cc: Keith.Bierman@Eng.Sun.COM, WG5 Mailing List Subject: Re: Re: (x3j3.1996-37) fodder for meeting In-Reply-To: Your message of "Mon, 29 Jan 96 13:19:04 CST." <199601291911.NAA02423@mixcom.mixcom.com> Date: Mon, 29 Jan 96 11:24:01 PST .... > >might be handy. Does anyone think this is a problem that ought to be > >fixed in this release? > > Absolutely _YES_. > > I propose a simple solution. Allow ANY kind of INTEGER in any I/O specifier that requires an INTEGER data object. I.e., a processor would be required to accept any INTEGER data object. Failure to do so would not be standard conforming. > > ---------- > Sincerely, > Craig T. Dedo Internet: Craig.Dedo@mixcom.com > Elmbrook Computer Services Voice Phone: (414) 783-5869 Which would require folks whose underlying operating environment can't support 64-bit integers to do???? They must accept it, but write garbage? require pl/1 style integer overflow detection? Produce a runtime error (at what cost for the normal well behaved case??).................................................................................................................................................................................................. The reason I did not propose text is because (as is almost always the case in language design) there are a lot of subtle side effects to any change, no matter how well intentioned.