Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.lang.fortran
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion implicit none
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Gordon Sande  
View profile  
 More options Mar 5 2000, 3:00 am
Newsgroups: comp.lang.fortran
From: G.Sa...@worldnet.att.net (Gordon Sande)
Date: 2000/03/05
Subject: Re: implicit none
Print | View thread | Show original | Report this message | Find messages by this author
On Sun, 05 Mar 2000 19:00:57 GMT, "James Giles"

<jamesgi...@worldnet.att.net> wrote:

>netnet wrote in message <38C22FA6.89C90...@netnetnet.net>...

>>netnet wrote:

>>> ...
>>> finds undefined or 'unitialized' variables in this case too: it works like
>>> ...

>>I'm not inventing new terminology here, it's just 'misspelling', read: uninitialized

>The two are not synonyms.  An unitialized variable is not necessarily
>one that has been misspelled.  Nor is it necessarily illegal.  Turning
>on a debugger option to detect unitialized variables will only tell
>you whether they've been initialized.  That's not even illegal if
>control hasn't reached the part of the program that initializes the
>variable yet.  (By the way, does it work for INTEGER, CHARACTER,
>and LOGICAL?  How?  There are no NANs for those data types.

The first system to systematically chase undefined variables that I am
aware of was WatFor for IBM 7040's. It used a cheat as it deliberately
stored bad parity into memory and then declared that all bad parity
references were for use of undefined variables. So on the exceedingly
rare case of a real bad parity you could be a bit confused. Other than
that you will read the fine print and find that there is a forbidden
value which is declared to be off limits. The bad parity check was a
thirty line assembly hack. The forbidden value scheme is a lot of work
as even the WatFor folks found out when they tried to replicate their
very good feature on IBM 360/xx's back when xx was still small like
50. So if you are using character data for other than printable and
other defined characters you have a risk of finding out about the fine
print that you may never have examined carefully. For systems without
NaNs for floating there are usually an adequate supply of otherwise
illegal configurations, logical is only supposed to have two states
(before vendor extensions) under control of the system and integers
cause the forbidden value to be a bother. This is particularly true if
the user and the system implementors have similar notions of
distinctive flag values.

None of which lessens the need for or utility of IMPLICIT NONE. I am
of the belt and suspenders school and like both. All of the arguements
so far against either IMPLICIT NONE or undefined variable checking
under a debugger seem to be of the "I never make mistakes so why do I
need the extra bother?" variety. There is some merit in the arguement
that having to declare variables is an interruption which seems to
rank with the bother of having to remove the declaration after its
temporary debugging use. I expect that the old idiom of "penny wise
and pound foolish" fits both better than their proponents would care
to admit. You are quite correct that undefined variable checking is
not a replacement for IMPLICIT NONE.

>For most implementations, *any* bit pattern is a legal value for those
>types.)

>You seem to be under the impression that identifying an unitialized
>variable automatically implies that an errror has occurred.  That's
>not necessarily the case.  The language does not require variables
>to be initialized.  They must become defined before you first try
>to evaluated them - but that can happen very late in a program's
>execution, and the variable can be passed around between procedures
>many times before that happens.

Unfortunately some of the systems that implement undefined variable
checking seem to treat the setting of an undefined variable in some
circumstances in a subroutine as an error according to their current
implementations. (They act as if one must reference it before setting
it in those curious circunstances!) They agree that such treatment is
in fact a bug but the fix seems a bit slow in coming. I do not know
the sorry internal details of the bug but it appears that this is in
fact a side effect of some other problem. Either way as a user I am
less than pleased, as the unnamed vendor knows rather well from the
apologies from their senior folks. One of the downsides of undefined
variable chacking is that it makes the system larger with all the
attendent bothers. The checklist purchasing which seems to greatly
value optimizations and to give zero credit for good debugging
facilities is not going to get a lot of good debugging support
developed. Bob Runyan's notion that diferent systems should be given
credit for differing strengths so much that one routinely uses several
systems has a lot going for it.

Poor implementation of a good idea is not directly an arguement
against the idea, and in this case it is a poor implementation of some
technically involved related issues which also seem to botch up the
subscript checking and even pointer passing with no debugging present.

>--
>J. Giles


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google