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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Thread: 101deb,15c6ed4b761968e6 X-Google-Attributes: gid103376,gid1094ba,gid101deb,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 25 May 2006 15:20:30 -0500 Message-ID: <447611A3.8080601@comcast.net> Date: Thu, 25 May 2006 16:20:51 -0400 From: Bob Lidral User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 Subject: Re: Checking for Undefined [was Re: Ada vs Fortran for scientific applications] References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <2006052509454116807-gsande@worldnetattnet> <4475DA0F.5030603@comcast.net> <2006052514574816807-gsande@worldnetattnet> In-Reply-To: <2006052514574816807-gsande@worldnetattnet> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.63.32.141 X-Trace: sv3-QxZKAVgHPBOXnMbh1kCaLD1r+k+FFOt37l+G/H7gv/XmfGCBnI3izocxQHpSu9YrXbo4bFfzIeWyf/y!qBGqInzUrIgfb7YtKJFnSLHYU2EQ7h535A/U2AcnITX3/hHCWZFfEvr12Lo4Pb8a X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:4471 comp.lang.fortran:10254 comp.lang.pl1:1713 Date: 2006-05-25T16:20:51-04:00 List-Id: Gordon Sande wrote: > [...] > > The original WatFor for IBM/7040 used a hardware hack. They set bad parity > but since they were a load and go system they had a symbol table around > and did the lookup for you. When WatFor moved to IBM/360 the feature was so > popular that they had to work hard to reproduce the feature. > > The Salford folks come form the same cafeteria for student debugging > environment and did the same feature. They even do it for automatic > storeage. They even set INTENT ( IN ) variables to undefined so a > user can set the undefined attribute/(bit configuration) themselves > if they are doing an internal storeage allocation themselves. Neat! > > NAG and Lahey/Fujitsu also have the capability but are missing the > setting of automatics if I have the features scoped out correctly. > > Initialization to signaling NANs if a quick and effective approximation. > Needs help from first the loader and then the storeage allocator. > > Until you have used it and it has saved a goodly block of time it > is a feature that many just shrug and say "That's nice". They do not > realize what they are missing. > > I am getting the impression from the silence of the cross postings > that undefined checking has only shown up in Fortran systems. > The exception is Salford who also have it for their C but one also > seems to notice that their C and Fortran seem to share a lot of features. > Well, the cross-posting silence could be from fear of getting involved in a language comparison religious war. I believe PL/C also had undefined checking -- but that was another load-and-go implementation. Checking for undefined by having the loader use signaling NaN as the default value for data doesn't cost much -- and then only at load time and not during run time -- for static storage. But it does cost at run time for automatic and heap storage. This may be OK for load-and-go student programs and debugging but may be unacceptable in production code. This might also explain why it's more popular in Fortran compilers. IIRC, Fortran didn't have recursion or a need for automatic variables until the Fortran 77 standard. Also note that signaling NaNs will catch uninitialized floating point arithmetic data but it's not clear there's any guarantee they will catch uninitialized integer or pointer data. I remember when CDC added that feature to the loader. When one of our customers upgraded to that version of the operating system, I suggested turning it on for their build procedures and explained, I thought, the advantages. Thereupon followed much wailing, wringing of hands, gnashing of teeth, and rending of garments because of the horrible number or error messages resulting. I was roundly chastised and ordered to turn off that feature forthwith. Clearly there couldn't be that many errors in the code because it was already working at another site and, besides, the language (JOVIAL) automatically initializes all storage to zero (it doesn't). While true they wouldn't encounter anywhere near that many errors during actual production runs, that was only by accident because large portions of memory were pre-set to zero by other programs and utilities -- as expected and required by their programming conventions. But equally clear to me, if the language really did pre-set that storage to zero, it wouldn't have mattered which value the loader used for initialization before the program executed. But I could never explain that to the customer so I am certain there were undetected and detected but undiagnosed errors that will remain until they migrate the project to another language. As Gordon wrote, it's an extremely handy tool. Bob Lidral lidral at alum dot mit dot edu