array argument checking style issue

From: Bastiaan Braams (braams_at_courant.nyu.edu)
Date: 06/17/04 

Date: 17 Jun 2004 08:17:34 -0700

I would like advice about a Fortran 90 style issue. I'm
developing a library of routines. They are small routines,
and the array arguments will be assumed shape arrays. If a
routine has more than one array argument then certain
identities must hold between the actual dimensions of the
various arrays. Should I test these identities in the
library procedures? Don't rush to say "yes, of course".

Let me provide an example and make the choice more precise.
My library contains subroutine foo, of which the critical
bits follow.

  subroutine foo (x, y, ...)
  real, intent (inout) :: x(0:)
  real, intent (in) :: y(0:)
  ...
  x = x+y
  return
  end subroutine foo

Obviously it is required that size(x).eq.size(y). I don't
want to add exit code arguments to my routines, but I might
add a test:

  if (size(x).ne.size(y)) then
   stop 'foo: size mismatch'
  endif

On the other hand, I will be perfectly happy if a code that
uses my routine foo and passes it incompatible arrays x and
y will simply halt with a meaningful system error message at
the point where "x = x+y" is executed. I'm not happy if the
code halts with "segmentation violation" and nothing else,
but if it halts and the system error message identifies
routine "foo" as the point where an error occurred, ideally
together with a call stack (traceback), then that is fine -
the user can then take it from there. Frequently there will
be several array arguments and multiple required identities,
and I would rather not clutter my code with tests.

So let's say that I write my code without explicit tests,
and I want to make sure that system error messages are
meaningful in the case just indicated. Now my question
becomes system dependent. Do I have to compile my code with
a debugging option? Can I choose a debugging option that
has very little effect on execution speed? All I want from
the option is a meaningful traceback when the code fails,
and I care very much about execution speed.

I believe that on Sun Solaris with Sun Fortran, if I compile
with optimization on and no other options then an error
message will be of the not so helpful kind: segmentation
violation or some such. I haven't explored the various
debugging options, and in any case I'm interested in other
systems as well.

Bas

Relevant Pages

  • Re: sorting roman numbers
    ... Ivo wrote: ... I've worked with roman numerals... ... VIIII is more appropriate for 9, but my routines stick with IX), at ... (You can try adding them into the $lookup array -- notice how the ...
    (comp.lang.php)
  • Re: I need the fastest routine
    ... I am hired to improve the diagnostic routines of a machine that tests hardware device. ... The hardware send "arrays" of doubles that must be checked according to their index. ... That's why I can't order the array. ...
    (borland.public.delphi.language.basm)
  • Re: Array argument bounds checking
    ... improperly-sized array arguments: an allocatable array of allocated ... I would like the compiler to detect all ... end subroutine foo ...
    (comp.lang.fortran)
  • Re: exploring a fortran(?) library
    ... I will write some fortran or C routines for use with matlab; I need the MAX efficiency in array management, because of intensive matrix multiplication and factorization. ...
    (comp.lang.fortran)
  • Re: I need the fastest routine
    ... I used one of the routines posted here in the project. ... There's a machine in the office that runs the diagnostics on newly assembled hardware devices. ... In the original project, the diagnostic routines were constantly processing the same array of double looking for min and max, processing a matrix to find the key values and then doing the diagnostic. ...
    (borland.public.delphi.language.basm)