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.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,803df5f3f60558d5 X-Google-Attributes: gid103376,public From: johnherro@aol.com (John Herro) Subject: Re: Uninitialized "out" parameters Date: 1996/07/23 Message-ID: <4t3f1u$t0u@newsbf02.news.aol.com>#1/1 X-Deja-AN: 169740504 sender: root@newsbf02.news.aol.com references: <31EEACDA.64880EEB@sage.inel.gov> organization: America Online, Inc. (1-800-827-6364) newsgroups: comp.lang.ada Date: 1996-07-23T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) writes: > The problem isn't OUT params in particular. > The problem is uninit vars. If Ada 05 is to > solve the problem, it ought to do so in a > uniform manner for all variables, not just > OUT parameters. I agree! Perhaps Ada 0Y should test for reads of unititialized variables at run time by default; this could be turned off with a pragma. When I was in college in the 60's, I wrote a Fortran IV program that stored into part of an array, and then accidentally read from a part of the array that hadn't been stored into. The run-time system caught it, and I was *delighted*! (I don't think my error could have been detected at compile time.) I think the Fortran compiler must have allocated much additional memory to keep track of which array elements were stored into. It was a very worthwhile expense! If "Ada, oh why?" does the same thing by default, it would use extra memory and CPU time, but improve reliability and increase the chances of detecting errors. This is certainly in keeping with the Ada philosophy. It's analogous to Ada doing bounds checking at run time, which can be turned off with a pragma. - John Herro Software Innovations Technology http://members.aol.com/AdaTutor ftp://members.aol.com/AdaTutor