Home > Archive > Fortran > January 2006 > debugging Fortran programs - looking for resources
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
debugging Fortran programs - looking for resources
|
|
| e p chandler 2006-01-10, 4:10 am |
| Within the past 6 months there have been a number of requests for help
with fairly large chunks of program that have been posted to this
newsgroup. I've grown a bit wary of throwing fish instead of providing
fishing instruction. I wonder if it would be helpful to future posters
to be able to point them to some guidelines and resources for debugging
Fortran (66 and 77) programs, particularly some that are available
on-line.
The Fortran tutorials and introductions that I have found on the net
have done a good job of explaining the language and its features but
the ones that I have seen do not cover testing and debugging in great
detail.
-- Elliot
| |
| Michel OLAGNON 2006-01-10, 4:10 am |
|
e p chandler wrote:
> Within the past 6 months there have been a number of requests for help
> with fairly large chunks of program that have been posted to this
> newsgroup. I've grown a bit wary of throwing fish instead of providing
> fishing instruction. I wonder if it would be helpful to future posters
> to be able to point them to some guidelines and resources for debugging
> Fortran (66 and 77) programs, particularly some that are available
> on-line.
>
> The Fortran tutorials and introductions that I have found on the net
> have done a good job of explaining the language and its features but
> the ones that I have seen do not cover testing and debugging in great
> detail.
>
Would http://www.fortran-2000.com/ArnaudRecipes/ provide the kind of pointers
that you want ?
Michel
| |
| Steve Lionel 2006-01-10, 4:10 am |
| On 21 Dec 2005 20:30:27 -0800, "e p chandler" <epc8@juno.com> wrote:
>The Fortran tutorials and introductions that I have found on the net
>have done a good job of explaining the language and its features but
>the ones that I have seen do not cover testing and debugging in great
>detail.
The documentation that accompanied the compiler can also be a useful resource.
Most commercial compilers, at least, include documentation on debugging using
the provided debugger. I'll agree that these don't tend to have tutorials on
general debugging techniques. I would observe, having debugged Fortran code
for going on 30 years, that there's little to be learned about debugging that
is Fortran-specific. The techniques needed are applicable to nearly all
languages and debugging tools.
Testing, of course, is another large subject, but again one that tends to be
language-neutral.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Richard E Maine 2006-01-10, 4:10 am |
| Steve Lionel <Steve.Lionel@REMOVEintelME.com> wrote:
> I would observe, having debugged Fortran code
> for going on 30 years, that there's little to be learned about debugging that
> is Fortran-specific. The techniques needed are applicable to nearly all
> languages and debugging tools.
I would generalize yet further. Although there are, of course, plenty of
Fortran-specific tricks and details, the most fundamental aspects of
debugging are broader than the field of computing. Our family doctor
(also a family friend) certainly recognized the commonality when I
described how I came up with recommendations for diagnostic tests for
his ailing home computer (flakey power supply, which was causing a broad
range of symptoms... and the very breadth of symptoms was the biggest
clue). He had to spend a long time acquiring the field-specific
knowledge base for medical diagnosis. But at the core, the techniques of
theorizing possible causes, and determining what further data could be
gathered that would contribute to the diagnosis - that skill is central.
(And alas, I don't know how to teach it; the Fortran-specific data I can
teach, but the basic debugging skill I can't).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| Richard E Maine wrote:
(sorry for the slow reply)
> Steve Lionel <Steve.Lionel@REMOVEintelME.com> wrote:
[color=darkred]
> I would generalize yet further. Although there are, of course, plenty of
> Fortran-specific tricks and details, the most fundamental aspects of
> debugging are broader than the field of computing.
(big snip)
I would agree except for one important case. The mistakes made by
beginning programmers tend to be more language specific. One I remember
specifically applicable to Fortran, and also some recent discussion, is
the result of forgetting to DIMENSION arrays in called subroutines or
functions. Unlike many other languages, Fortran understands this as
passing a function address for the called routine to use. In many cases
this results in executing the data in the passed array as code.
As one gets deeper into the language, though, I do agree that more
general debugging methods apply. Maybe with one more exception, for
languages designed to be interpreted.
-- glen
| |
| N. Shamsundar 2006-01-10, 4:11 am |
| glen herrmannsfeldt wrote:
> Richard E Maine wrote:
>
> (sorry for the slow reply)
>
>
>
>
>
>
>
> (big snip)
>
> I would agree except for one important case. The mistakes made by
> beginning programmers tend to be more language specific. One I remember
> specifically applicable to Fortran, and also some recent discussion, is
> the result of forgetting to DIMENSION arrays in called subroutines or
> functions. Unlike many other languages, Fortran understands this as
> passing a function address for the called routine to use. In many cases
> this results in executing the data in the passed array as code.
At one time, this happened in C, as well:
int x[3];
x[0]=2;
x[1]=x(0)+3;
At the time, I was using one of the first C compilers for CPM-86; this
compiler not only gave no error messages, but compiled a function call
to the base address of the array!
> <--CUT-->
>
> -- glen
>
Another more recent bug/misconception about C that happened to me:
strchr(string,c)
returns a pointer to the terminal null of the string if c happens to be
NULL. I had developed a habit of regarding the terminal null of the
first argument as something contributed by the compiler and not a true
part of my string. I had to readjust my understanding to "every C string
contains a null".
N. Shamsundar
University of Houston
| |
| Richard E Maine 2006-01-10, 4:11 am |
| N. Shamsundar <shamsundar_at_@uh.edu> wrote:
> I had to readjust my understanding to "every C string
> contains a null".
Wandering a bit off subject for clf, but if you mean that literally,
perhaps you should readjust further, as it isn't true. There are
probably restrictions that make it true, though my C is weak enough that
I'm not confident of being able to express such restrictions correctly.
For example, I think it probably true that every literal quoted C string
contains a null. There are plenty of C functions that assume their
arguments contain a null... and violations of that assumption are a
common source of various bugs and sometimes consequent security holes.
Off the top of my head, the first place I recall a counterexample I can
cite is in the man page for strncpy. The man page on this system (my
Mac) includes a sentence
"Note that it does not NUL terminate chararray because the length of
the source string is greater than or equal to the length argument."
Now this is is followed by admonitions about how you will need to do any
needed null termination yourself in such situations. Having a string
without null termination is "clearly" regarded as a potential problem.
But it is a problem that can occur.
Perhaps to bring back a token reference to Fortran, I might note that a
quite likely way for us Fortraners to get C strings without null
termination is from Fortran passing character data to C. In general,
such strings will not have nul termination in C. There are special cases
where some compilers will do it for you (notably with literal strings),
and of course you can explicitly add a null terminator yourself. But
there isn't inherently a null terminator there just by virtue of being a
string.
P.S. It is possible that I misunderstand your usage of the term "C
string". I'm taking it to mean anything that a "char *" might point to.
If you mean something like a literal quoted string, then I take it all
back.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2006-01-10, 4:11 am |
| Richard E Maine wrote:
> N. Shamsundar <shamsundar_at_@uh.edu> wrote:
[color=darkred]
> Wandering a bit off subject for clf, but if you mean that literally,
> perhaps you should readjust further, as it isn't true. There are
> probably restrictions that make it true, though my C is weak enough that
> I'm not confident of being able to express such restrictions correctly.
> For example, I think it probably true that every literal quoted C string
> contains a null. There are plenty of C functions that assume their
> arguments contain a null... and violations of that assumption are a
> common source of various bugs and sometimes consequent security holes.
I am not ready to argue it in comp.lang.c, but I believe to be a
"C string" it has to be null terminated. Otherwise it is just an
array of char, which is perfectly legal as long as it isn't passed
to a routine expecting a null terminated string.
> Off the top of my head, the first place I recall a counterexample I can
> cite is in the man page for strncpy. The man page on this system (my
> Mac) includes a sentence
> "Note that it does not NUL terminate chararray because the length of
> the source string is greater than or equal to the length argument."
> Now this is is followed by admonitions about how you will need to do any
> needed null termination yourself in such situations. Having a string
> without null termination is "clearly" regarded as a potential problem.
> But it is a problem that can occur.
I notice that it is called chararray and not string. Though there
is claim that all keywords starting with str are reserved in C, so one
should not name a variable string.
> Perhaps to bring back a token reference to Fortran, I might note that a
> quite likely way for us Fortraners to get C strings without null
> termination is from Fortran passing character data to C. In general,
> such strings will not have nul termination in C. There are special cases
> where some compilers will do it for you (notably with literal strings),
> and of course you can explicitly add a null terminator yourself. But
> there isn't inherently a null terminator there just by virtue of being a
> string.
Or write C routines that accept Fortran CHARACTER arguments, including
the length information.
> P.S. It is possible that I misunderstand your usage of the term "C
> string". I'm taking it to mean anything that a "char *" might point to.
> If you mean something like a literal quoted string, then I take it all
> back.
It doesn't have to be literal, but I believe it does need the '\0'.
-- glen
| |
| e p chandler 2006-01-10, 4:11 am |
|
Michel OLAGNON wrote:
> e p chandler wrote:
>
> Would http://www.fortran-2000.com/ArnaudRecipes/ provide the kind of pointers
> that you want ?
>
> Michel
Thanks for the great reference - very helpful and concise.
Addendum:
I discovered this while surfing:
Gilberto Urroz (Utah State University) has a page on G77 for
*engineering students*. Part way down the page is a link to a PDF
document which discusses debugging G77 programs in some detail. It
includes a nice list of common types of Fortran programming errors.
http://www.engineering.usu.edu/cee/...an77Course.html
-- Elliot
| |
| Dave Thompson 2006-01-11, 3:57 am |
| On Thu, 05 Jan 2006 06:39:03 -0600, "N. Shamsundar"
<shamsundar_at_@uh.edu> wrote:
> glen herrmannsfeldt wrote:
<snip: A(X) not declared as array is function>
> At one time, this happened in C, as well:
>
> int x[3];
> x[0]=2;
> x[1]=x(0)+3;
>
> At the time, I was using one of the first C compilers for CPM-86; this
> compiler not only gave no error messages, but compiled a function call
> to the base address of the array!
>
Even in early C that shouldn't have happened with the declaration in
scope. (The equivalent in B would, but I'm not sure if it used the
same syntax.) Now if you put them in separate translation units (i.e.
separately compiled source files) or even just rearrange to:
func1 ()
{ x (0); } /* treat x as function */
int x [10]; /* it's actually an array, maybe with code in it? */
main ()
{ func1 (); }
that will 'work' (in the sense of slide by on most systems) until C99,
which is not yet widely implemented, and thus in practice still.
and Thu, 5 Jan 2006 08:07:35 -0800, nospam@see.signature (Richard E
Maine) wrote:
> N. Shamsundar <shamsundar_at_@uh.edu> wrote:
>
>
or more specificallly _ends_ with a null.
> Wandering a bit off subject for clf, but if you mean that literally,
> perhaps you should readjust further, as it isn't true. There are
> probably restrictions that make it true, though my C is weak enough that
> I'm not confident of being able to express such restrictions correctly.
In C a string is _defined_ as a 'contiguous sequence' (array) of
characters terminated by a null. You can have other arrays of char,
and even build your own string operations/functions for them, but C
doesn't call them strings.
> For example, I think it probably true that every literal quoted C string
> contains a null. There are plenty of C functions that assume their
> arguments contain a null... and violations of that assumption are a
> common source of various bugs and sometimes consequent security holes.
>
To be a bit more precise, the runtime value of a string literal in C
always has a null terminator added. There are some cases where the
mapping from literals to values is not one-to-one, and it is the value
that has the null added rather than the literal as such.
It's fairly rare that C strings (more precisely, things intended to be
strings in a purely C program) fail to have null terminators, because
there are rather few things that create such. If anything the reverse:
'stray' nulls get in the middle of text and terminate it prematurely.
What is most common is for a string that should have length <= N to
actually be longer, and clobber (or sometimes be clobbered back by)
whatever follows it in memory. In the (most) direct security holes,
this is a stack link that happens to follow a stack-allocated buffer.
Interlanguage operations, as you note below, are prone to cause lack
of null termination. OTOH languages with fixed-length or at least
known-length string variables, which is practically everything else
including Fortran, of course can much more easily avoid overruns.
> Off the top of my head, the first place I recall a counterexample I can
> cite is in the man page for strncpy. The man page on this system (my
> Mac) includes a sentence
>
> "Note that it does not NUL terminate chararray because the length of
> the source string is greater than or equal to the length argument."
>
> Now this is is followed by admonitions about how you will need to do any
> needed null termination yourself in such situations. Having a string
> without null termination is "clearly" regarded as a potential problem.
> But it is a problem that can occur.
>
strncpy() is the only str* routine with this 'feature' of producing
something that is not a C-valid null-terminated string, for hysterical
raisins: it was originally created before most of the rest of the
standard library, for use with some fixed-length data structures that
aren't actually C strings, most importantly the 14-byte directory
entries in the original Unix filesystem. With the benefit of 30 years
hindsight, it probably should have been named differently.
There are also several mem* routines somewhat confusingly in the same
header <string.h> which don't expect or do null-termination.
> Perhaps to bring back a token reference to Fortran, I might note that a
> quite likely way for us Fortraners to get C strings without null
> termination is from Fortran passing character data to C. In general,
> such strings will not have nul termination in C. There are special cases
> where some compilers will do it for you (notably with literal strings),
> and of course you can explicitly add a null terminator yourself. But
> there isn't inherently a null terminator there just by virtue of being a
> string.
>
> P.S. It is possible that I misunderstand your usage of the term "C
> string". I'm taking it to mean anything that a "char *" might point to.
> If you mean something like a literal quoted string, then I take it all
> back.
and Thu, 05 Jan 2006 19:36:44 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
>
> I notice that it is called chararray and not string. Though there
> is claim that all keywords starting with str are reserved in C, so one
> should not name a variable string.
>
_Identifiers_ beginning with str followed by a lowercase letter are
reserved (from user code) if <string.h> is #include'd -- I believe as
macro names, which effectively means for all purposes, though this
isn't totally explicit -- and as external (linker) names always.
That doesn't impose any restrictions on man pages or other
documentation, or on the contents of <string.h> itself since that is
(in) the implementor's domain. But per above strncpy() does not
consistently treat its argument as a C string, so it is useful,
arguably vital, to stress this to the people using it, presumably in
most cases C programmers who are used to null termination.
- David.Thompson1 at worldnet.att.net
| |
|
| "Dave Thompson" <david.thompson1@worldnet.att.net> wrote in message
news:0d69s1p26g0ohva5vaspgftkatia0q4hs6@
4ax.com...
> Interlanguage operations, as you note below, are prone to cause lack
> of null termination. OTOH languages with fixed-length or at least
> known-length string variables, which is practically everything else
> including Fortran, of course can much more easily avoid overruns.
Interfacing C with PL/I avoids these difficulties because PL/I
has a specific data type for just such compatablity (namely,
a NUL terminated string data type).
This is in addition to PL/I's regular fixed and varying-length
string data types.
| |
| Rich Townsend 2006-01-11, 9:57 pm |
| robin wrote:
> "Dave Thompson" <david.thompson1@worldnet.att.net> wrote in message
> news:0d69s1p26g0ohva5vaspgftkatia0q4hs6@
4ax.com...
>
>
>
>
> Interfacing C with PL/I avoids these difficulties because PL/I
> has a specific data type for just such compatablity (namely,
> a NUL terminated string data type).
> This is in addition to PL/I's regular fixed and varying-length
> string data types.
>
>
Plonk.
| |
| glen herrmannsfeldt 2006-01-12, 3:58 am |
| robin wrote:
> "Dave Thompson" <david.thompson1@worldnet.att.net> wrote in message
> news:0d69s1p26g0ohva5vaspgftkatia0q4hs6@
4ax.com...
[color=darkred]
> Interfacing C with PL/I avoids these difficulties because PL/I
> has a specific data type for just such compatablity (namely,
> a NUL terminated string data type).
> This is in addition to PL/I's regular fixed and varying-length
> string data types.
Since they use the C library, it shouldn't be too surprising.
Every IBM mainframe software system has a three letter code which
is used as a prefix for all module and error messages. The PL/I
optimizing compiler has the PLI prefix (or is it the library, I
forget now). The current PL/I library has the CEE prefix.
I wonder where that came from !
-- glen
|
|
|
|
|