Re: How to avoid undesired default values?

Gordon Sande wrote:

On 2008-10-29 13:46:08 -0300, Dave Allured <nospam@xxxxxxxxxx> said:

Gordon Sande wrote:

On 2008-10-29 12:36:59 -0300, Dave Allured <nospam@xxxxxxxxxx> said:

Gordon Sande wrote:

On 2008-10-28 12:33:50 -0300, Dave Allured <nospam@xxxxxxxxxx> said:

qquito wrote:
...
In Fortran 90, you can use "implicit none" to prevent unspecified
variables from stealing into your codes. But how do you prevent
specified variables from taking on unassigned values?

In other words, I may specify an integer or real number but forget to
assign a value to it. Then this variable automatically assumes a value
which could be 0, or 1, or a number with an extremely large absolute
value.

I am using "gfortran" to compile my codes. Is there an option for the
compiler to tell me that certain variables need assigned values?

glen herrmannsfeldt wrote:
...
Since compile time testing isn't usually reliable enough,
I believe he wants run-time testing. 'tell me' seems to indicate
more than just initializing the variables to known values.
Well, initializing reals to SNaN might work, but not for integer,
logical, or character.

I agree, though, that it is hard to be sure.

Is there any interest in adding run-time testing to gfortran?

Yes!

Simplest would be one compiler option to enable checking for signal
values, for all data types. Other desirable features would be:

* Including or excluding variables by name. (I think
part 1 is just what the OP requested.)

* Controlling init checking by individual data types.

* Options by data type for user-specified specify signal
values, instead of default signal values.

* Controlling init checking by individual program units.

* Controlling init checking within blocks of code.

* Controlling init checking at run time.

My thanks to anyone who puts their time in to implement any of this.

--Dave

There is the basic issue with debugging that you do not know where the
problem is. If you did know you would not be debugging. See the repeated
instructions to show the problem rather than describing it as the fact that
you have to ask shows that you do not know enough to describe it correctly.

If you knew enough to be able to use the extra features you would not need
them! Have you actually used a system with the capability to find a bug
that was more difficult than a seeded bug used to illustrate the capability?

When I read the list of features I thought that it was very clever but
reminded me of the chap who knew the prices of everything the values of
nothing.

What do you think of subscript range checking as a debugging feature?

--Dave

Another very useful capability. Much more widely available.

Your list of extras could equally be applied to subscript checking
but never is because experience has shown that you either need
"everywhere" or you do not need it. The notion that you could
know enough to turn it on or off selectively just does not hold.
Just like it does not hold for undefined variable checking.

There are even a few compilers that will check constant subscripts
against fixed dimensions but that does not remove the need for runtime
checking of subscripts. One of the great features of F90 and assumed
shape (the use of ":"s) is that the loophole of the assumed size
(the use of "*"s) of F77 semantics can be plugged. The good debugging
compilers know how to avoid this issue but it takes a lot of extra work.

When I an debugging with either Lahey or Siverfrost I turn on both. With
NAG I use one or the other (more or less alternately) because it drives
the GCC backend to distraction (and paging death) if I enable both at once.
I can compile and run twice while the combined compile is still paging
away! Nobody ever claimed GCC could beat the vendor compilers on their
home machines. Efficient memory use is not one of its claimed features.

Well my point is that checking for uninitialized variables is about as
useful as subscript range checking, therefore a reasonable request.

Yes I agree that location specific or run time control are more esoteric
and would require more foresight by the user. Consider them the lowest
priority of my requests. I had in mind a scenario where one section of
a program needed debugging, but another section ran through a wide range
of numbers and hit the signal value by accident.

The default floating point value is typically not a valid floating point
bit configaration. The default integer is typically a very large negative
to keep out of the way of most uses. The default character is typically some
nonprinting nonascii to avoid real text. If accidental hits were an issue
the existing vendors would provide workarounds. Mostly they just document
the values to explain what happens when they are output. Nice theory that
there is a problem. But as they say "in theory, theory and practice are the
same but in practice they are not".

Here it would be nice
to be able to insert a couple of debug lines that turn the checker off,
then on again, in a simple minded, incrementally debugging sort of way.

BTW as far as I know, subscript checking is naturally controllable by
program unit at compile time, because source files can be compiled
separately with and without --bounds-check (or -C), then linked. In
practice this happens all the time with run time libraries. So I would
expect #4 in my list of extras to fall out naturally without extra
effort.

Depends on how rigourouus the checking is for assumed size. Do you believe
the local lies the programmer tells or do you work your way back to the
original declarations for the truth? Some vendors do not permit the mix
and match as they pass lots of extra on calls while debugging.

Mix and match with subscript checking works well on the two platforms
and several compilers at my office. I assume that the various app
libraries are well vetted, and user code (my own and others) is not;
therefore bounds checking need be active only in the latter. This is
not always the case, but often enough to be extremely useful and save us
plenty of debugging time.

I wonder if anyone from gfortran is listening to any of this. ;-)

--Dave
.

Relevant Pages

  • Re: How to avoid undesired default values?
    ... I am using "gfortran" to compile my codes. ... Controlling init checking by individual program units. ... If you did know you would not be debugging. ... What do you think of subscript range checking as a debugging feature? ...
    (comp.lang.fortran)
  • Re: How to avoid undesired default values?
    ... I am using "gfortran" to compile my codes. ... Controlling init checking by individual program units. ... If you did know you would not be debugging. ... useful as subscript range checking, ...
    (comp.lang.fortran)
  • Re: Large Ruby Apps ?
    ... all compile perfectly with all warnings on. ... In those languages, I rely on unit testing, static checkers, AND runtime checking to insure that I get it right. ... i've been writing pretty much nothing but ruby for 5 years now and have never, like never, required a debugger or spent more that an hour debugging my code. ...
    (comp.lang.ruby)
  • RE: Referencing a multifile assembly
    ... >> Codes: ... >> namespace ParentProject ... >> When you had code finish animal.cs, compile it with: ... > csc /t:module animal.cs ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Embedding assembler in a language
    ... the type of a variant. ... For single operand codes, this is then used ... All this things can be decided at compile time. ... (probably every time an array element is accessed). ...
    (comp.lang.misc)