HDTenEightyP/NetNews huggingface dataset:
From: cheryl@gallant.apple.com (Cheryl Lins)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon-2, WITH-Statement, problem
Summary: looks like compiler bug
Keywords: WITH, Oberon-2, DECoberon
Date: 6 Oct 92 21:22:28 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <1992Oct6.195605.22657@email.tuwien.ac.at> ulrich@mips.complang.tuwien.ac.at writes:
>(*
>	Hello, I have some problems in understanding the WITH-statement
>	in Oberon-2 and would appreciate some help.
>
>	As far as I understood the Oberon-2 report, the procedure Subel1
>	below, should be equivalent to the procedure Subel2.
>	However, in Subel2 an error is reported by the compiler.
>	Even if a type guard is added (Subel3), the error remains.
>	(The procedures are a stripped down version of some more
>	useful code, indeed.)
>
>	The platform was DECoberon Release 2.6
>	(Oberon.2.6.tar.Z last modified Oct 3 21:09)
>	
>
>	Thanks in advance
>	Ulrich
>*)
>
>MODULE StatementWITH;
>TYPE
>	T0 = POINTER TO T0X;
>	T0X = RECORD END;
>
>	T1 = POINTER TO T1X;
>	T1X = RECORD(T0X) ARG: POINTER TO ARRAY OF T0 END;
>
>PROCEDURE Subel1(t0: T0);
>BEGIN
>	Subel1(t0(T1).ARG[0])
>END Subel1;
>
>PROCEDURE Subel2(t0: T0);
>BEGIN
>	WITH t0: T1 DO
>		Subel2(t0.ARG[0]) (* error 113 "incompatible assignment *)
>	END
>END Subel2;
>
>PROCEDURE Subel3(t0: T0);
>BEGIN
>	WITH t0: T1 DO
>		Subel3(t0(T1).ARG[0]) (* error 113 "incompatible assignment" *)
>	END
>END Subel3;
>END StatementWITH.
>

A version that compiles follows:

[types and Subel1 deleted]

PROCEDURE Subel2(t0: T0);
VAR
  t: T0;
BEGIN
        WITH t0: T1 DO
  	  t := t0.ARG[0];
        END;
        Subel2 (t)
END Subel2;

(* it looks like a front-end bug in Subel2 as there should be no difference
   between assignment to a variable and passing the designator as a param
   (at least in this case.)
*)

PROCEDURE Subel3(t0: T0);
BEGIN
        Subel3(t0(T1).ARG[0])
END Subel3;

(* The WITH statement is unnecessary with the guard. *)


I have written quite a bit of code using the WITH statement and haven't
encountered this bug. I suspect it's related to the use of the open array
rather than a general problem with WITH statements.


-- 
Cheryl Lins  Oberon Paladin  lins@apple.com
Newsgroups: comp.lang.modula2
From: ulrich@mips.complang.tuwien.ac.at (Ulrich Neumerkel)
Subject: Oberon-2, WITH-Statement, problem 
Keywords: WITH, Oberon-2, DECoberon
Reply-To: ulrich@mips.complang.tuwien.ac.at
Organization: Technische Universitaet Wien, Institut fuer Computersprachen
Date: Tue, 6 Oct 1992 19:56:05 GMT

(*
	Hello, I have some problems in understanding the WITH-statement
	in Oberon-2 and would appreciate some help.

	As far as I understood the Oberon-2 report, the procedure Subel1
	below, should be equivalent to the procedure Subel2.
	However, in Subel2 an error is reported by the compiler.
	Even if a type guard is added (Subel3), the error remains.
	(The procedures are a stripped down version of some more
	useful code, indeed.)

	The platform was DECoberon Release 2.6
	(Oberon.2.6.tar.Z last modified Oct 3 21:09)
	

	Thanks in advance
	Ulrich
*)

MODULE StatementWITH;
TYPE
	T0 = POINTER TO T0X;
	T0X = RECORD END;

	T1 = POINTER TO T1X;
	T1X = RECORD(T0X) ARG: POINTER TO ARRAY OF T0 END;

PROCEDURE Subel1(t0: T0);
BEGIN
	Subel1(t0(T1).ARG[0])
END Subel1;

PROCEDURE Subel2(t0: T0);
BEGIN
	WITH t0: T1 DO
		Subel2(t0.ARG[0]) (* error 113 "incompatible assignment *)
	END
END Subel2;

PROCEDURE Subel3(t0: T0);
BEGIN
	WITH t0: T1 DO
		Subel3(t0(T1).ARG[0]) (* error 113 "incompatible assignment" *)
	END
END Subel3;
END StatementWITH.

-- 
Ulrich Neumerkel, ulrich@dec4.wu-wien.ac.at ulrich@mips.complang.tuwien.ac.at
TU-Wien, Vienna University of Technology, +431 58801 4477 fax +431 5057838
Institut fuer Computersprachen E185/1 Argentinierstr.8/4, A-1040 Wien Austria
From: Robert.Bergermann@f2002.n241.z2.fidonet.org (Robert Bergermann)
Newsgroups: comp.lang.modula2
Subject: FST V3.0 - WHERE CAN I GE
Date: Sat, 03 Oct 92 19:59:02 PST
Organization: FidoNet node 2:241/2002 - M2-Tek, Bremen

Hi!

 > randy@psg.com   ...!uunet!m2xenix!randy writes:
 > Roger assures me that by next week I will have it here and can
 > post for FTP and FidoNet .REQuest.
 >   ftp.psg.com:~/pub/modula-2
 >   1:105/6  V.32bis

Thanx for your answer. Can you please mail me, if it's on the system and please tell me the times it's open for a frequest?!

Tschau
  Robert

Robert Bergermann
2:241/2002 +49-421-591113 (fidonet)
baer@m2tek.fido.de (usenet)


--  
uucp: uunet!m2xenix!puddle!2!241!2002!Robert.Bergermann
Internet: Robert.Bergermann@f2002.n241.z2.fidonet.org
From: Robert.Bergermann@f2002.n241.z2.fidonet.org (Robert Bergermann)
Newsgroups: comp.lang.modula2
Subject: FST V3.0 - WHERE CAN I GE
Date: 29 Sep 92 04:14:00 GMT
Article-I.D.: puddle.4414.2ACA09E7
Organization: FidoNet node 2:241/2002 - M2-Tek, Bremen

Hi!

 >  If you can't find it in the ftp pool...

Is there any fidonet node where I can frequest the v3 of FST? Perhaps sombody knows an european address, but one in the USA is also ok.

Tschau
  Robert   (fidonet 2:241/2002, internet baer@m2tek.fido.de)


--  
uucp: uunet!m2xenix!puddle!2!241!2002!Robert.Bergermann
Internet: Robert.Bergermann@f2002.n241.z2.fidonet.org
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.modula2
Subject: Re: Exceptions
Date: 2 Oct 92 09:46:47 GMT
	<3565@creatures.cs.vt.edu>
Organization: Department of Computer Science, University of Manchester
In-reply-to: brueni@csgrad.cs.vt.edu's message of 1 Oct 92 16:40:34 GMT

In article <3565@creatures.cs.vt.edu> brueni@csgrad.cs.vt.edu (Dennis Brueni) writes:
   FROM A COMPILER'S POINT OF VIEW

	   PROCEDURE Divide(a,b: T):T;
	   PROCEDURE Divide(a,b: T):T RAISES {DivideByZero};

   The second example captures more information about the Divide procedure.
   This information can later be used by the compiler to enforce correct
   usage of the procedure.  Hence the argument favoring exception handling
   is very much identical to the argument in favor of strong typing.  

Could you expand on what exactly the compiler should check and how you
think it would be done?

bevan
Newsgroups: comp.lang.modula2
From: davis@aurs01.UUCP (Alan Davis)
Newsgroups: comp.lang.modula2
Subject: writing error handlers (was Re: Why 3 button mice in Oberon?)
Date: 2 Oct 92 01:51:41 GMT
Reply-To: davis@aurw17.aur.alcatel.com.UUCP (Alan Davis)
Organization: Alcatel Network Systems, Raleigh NC

In article <717928825snx@black.demon.co.uk> tchannon@black.demon.co.uk (Tim Channon) writes:
>
>Is it reasonable to think of programming as fully defining the error system 
>with the side effect of producing the intended program? 
>

Durn if that isn't what *I* end up with most times :-)
The worst thing you can do to a sw engineer is make 'em write programs for
*users*.





Alan Davis                      aur : davis@aurfs1
Alcatel Network Systems         BIX : adavis
adavis@rockdal.aud.alcatel.com  CIS : 72317,3661
Newsgroups: comp.lang.fortran
From: bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor)
Subject: Re: F77 Compilers for MS-DOS PC's
Organization: /usr/local/lib/news/organization
Date: Mon, 28 Sep 1992 13:16:26 GMT

In article <1992Sep28.092410.2472@news.Hawaii.Edu> tholen@galileo.ifa.hawaii.edu (Dave Tholen) writes:

>WATCOM's product comes with a profiler, however, which is something
>Microsoft's does not.

Microsoft has a Source Profiler which works with all it language
products, and works under OS/2. The Programmer's Shop sells it
for $75. I dont know if educational discounts are available.

Dov


Newsgroups: comp.lang.fortran
From: saastad@spot.Colorado.EDU (Ole W Saastad)
Subject: Re: scientific object-oriented programming?
Organization: University of Colorado, Boulder
Date: Fri, 2 Oct 1992 17:39:28 GMT


Simula !
It is the language for object oriented programming.
In the 60ties it was used for nuclear recator simulation.
Today it is teached at University of Oslo. Nice language !
Give it a try, free compilers and X11 libs exists. 

-- 
Ole W Saastad       "Fat trout trailer park"
Dept. of Chemistry University of Oslo Norway.
Now at University of Colorado at Boulder / CIRES ,  Atmospheric Chemistry.
From: khb@chiba.Eng.Sun.COM (chiba)
Newsgroups: comp.lang.fortran
Subject: Re: Is this a Compiler Bug ?
Date: 2 Oct 92 13:42:24
Organization: Sun MegaSystems
NNTP-Posting-Host: chiba
In-reply-to: jlg@cochiti.lanl.gov's message of Fri, 2 Oct 1992 17:45:12 GMT


In article <1992Oct2.174512.16640@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

   implementation is ASCII, the above program is standard conforming
   *as is*

Not true. Use of anything not in the FORTRAN character set renders your
program beyond the scope of the standard. The "escape hatch" for
constants and comments is that "processor" in the FORTRAN standard
sense is not the physical CPU, nor the CPU+OS, it is merely that thing
which handles FORTRAN programs ... *that* processor cannot be assumed
to handle all of ASCII even if the CPU itself can.

...
   be solved.  In the above case, there is no reason that `\' should
   not be simply accepted.

Yes there is. A long standing Unix tradition of usage of \ dating back
to the first Unix f77 compiler. Changing this behavior by default
would break some large (but unknown in precise size) set of existing
codes. 
--
----------------------------------------------------------------
Keith H. Bierman    keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SunPro 2550 Garcia MTV 12-40             | (415 336 2648) fax 964 0946
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992
From: lionel@quark.enet.dec.com (Steve Lionel)
Newsgroups: comp.lang.fortran
Subject: Re: What are pointers
Date: 5 Oct 92 20:21:36 GMT
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH


As regarding the discussion about the professor who told a Fortran class to
"use pointers", perhaps he was familiar with Cray's Fortran compiler which
provides a POINTER statement or one of the many compilers from other vendors
which support this feature.  I have noted that instructors often have trouble
distinguishing standard language features from extensions when they teach
a language.  Note that the Cray POINTER feature in concept, though not in
syntax, to Fortran 90's, if one ignores deferred shape lists and the like.

--

Steve Lionel                    lionel@quark.enet.dec.com
SDT Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: bibhas@pico.engr.mun.ca (Bibhas Bhattacharya)
Newsgroups: comp.lang.fortran
Subject: Re: Calling FORTRAN from C... Update:
Keywords: FORTRAN C
Date: 4 Oct 92 02:50:41 GMT
Organization: Memorial University of Newfoundland

bibhas@pico.engr.mun.ca (Bibhas Bhattacharya) writes:


> 
> Did cc say that "sum" was undefined or "sum_"?  Some FORTRAN compilers
> append an underscore to all external names.  If that is the problem,
> replacing "sum" with "sum_" in your C program should solve it.
> 
> 					Yours truly,
That seemed to help, at least the function was resolved. Now the error
message is: (forlib is the library I created):

cc fortran.c forlib
ld:
Undefined:
for__rtl_version_string
for_u__rtl_version_string
cvt__rtl_version_string
ots__rtl_version_string
for_stop

I followed the right options with f77 to create the .o file and then used
"ar" and "ranlib" to create the library.
Any pointers.
Bibhas.
Newsgroups: comp.lang.fortran
From: suzuki@loon.geog.ubc.ca (Natalie Suzuki)
Subject: What is -noslib?
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Thu, 1 Oct 1992 22:18:57 GMT


I am trying to compile some software prepared for an fc compiler
on an IBM RS6000.  Could someone please tell me what the 
command option "-noslib" and the flag "-zero" refer to, and
what the equivalent option/flag would be on xlf?  I'd
appreciate a reply by e-mail.  Thanks in advance!

Natalie Suzuki
University of British Columbia
Newsgroups: comp.lang.fortran
From: tholen@galileo.ifa.hawaii.edu (Dave Tholen)
Subject: Re: F77 Compilers for MS-DOS PC's
Organization: University of Hawaii
Date: Mon, 28 Sep 1992 09:24:10 GMT

> Could someone who used both MS-FORTRAN 5.x and the WATCOM 9.0
> compare the debugging facilities of WATCOM ver. MS-FORTRAN ?
> MS-FORTRAN has the CodeView debugger as well compiler switches
> which would point to the line in code in which an array is out 
> of bounds or other floating-point exceptions occured. 

WATCOM has WVIDEO, which is their counterpart to CodeView.  I've only
briefly looked at it.  At the present time, I'm mainly converting
existing, working code from 16-bit to 32-bit operation, so no debugging
has been necessary.  Thus I'm not in a position to make a detailed
comparison, but at first glance, they seemed to have similar capabilities.
WATCOM's product comes with a profiler, however, which is something
Microsoft's does not.

By the way, WATCOM's tech support provided the hint that the single
precision version of paranoia should be compiled with precision
optimizations enabled.  I've verified that both the single and double
precision versions work well, with the exception of the noted floating
point stack check, which I managed to eliminate by compiling with the
/SAVE option.

Similarly, if the two source files are compiled with Microsoft's compiler
and the /Op switch, the radix is properly determined and the program gets
much farther along.  But both die and cannot be restarted properly after
the overflow occurs.  WATCOM's executables do make it to the end of the
test, after three (or was it two?) restarts.
From: jwhite@oasys.dt.navy.mil (Joseph White)
Newsgroups: comp.lang.fortran
Subject: Re: FORMAT overhead
Date: 2 Oct 92 16:17:19 GMT
Article-I.D.: oasys.25862
Organization: Annapolis Detachment, CARDEROCKDIV, NSWC  Code 2723 
	      (formerly David Taylor Research Center, Annapolis MD)

In article <1992Oct2.153522.10241@news.eng.convex.com> patrick@convex.COM (Patrick F. McGehearty) writes:

>Anyone know of a fundamental reason why free format might be twice as
>fast as a specified format?

It would seem to me that a free format read would be faster than a formatted
read.  In the free format case, the read statement has to parse the
input line, and read in the input, translating it from 'text' representation
to the computers binary representation, make sure it's a valid number, 
and it's all done.
In the formatted read, the read statement has to parse the format statement 
to figure out how it is supposed to treat this particular input, go 
get an exact number of digits, convert it to internal binary form, and 
then error check it.  I would think the finding of the format, and parseing
it would take longer than finding out it free format, and then doing
it.

Of course, I don't write compliers, and the above is just what I came
up with, since pondering the original article.  Therefore, it could
all be wrong, but to me it makes sense.

Joe White
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Is this a Compiler Bug ?
Date: 5 Oct 92 17:49:43 GMT
Article-I.D.: newshost.1992Oct5.174943.22483
Organization: Los Alamos National Laboratory

In article <7442@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
|> About whether to use '\' or '\\'.
|> 
|> In article <1992Oct2.174512.16640@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:

|>  > [...]    Now, as I pointed out before, few implementations are
|>  > strictly standard conforming with respect to character literals
|>  > because of control characters.
|> It depends on what standard you take (like in a previous thread about
|> the use of LF as New-Line).  In this case the original standard only
|> talked about Fortran characters (which are uppercase letters, digits
|> and some punctuation).  [...]

The Fortran 77 standard is the one I quoted here.  I believe it was 
certified as a standard before the first widely available UNIX Fortran
implementation - or, in any case, soon afterward.  The only place I can
even imagine such a poorly chosen character escape mechanism occuring
in on UNIX.  Since an escape of that kind is unnecessary, and the
existing standard requires all processor representable characters
to be allowed in strings, the `\' should be so allowed.  Or are you
claiming that `\' is not processor representable (in which case there
would be no way of getting it - not even as an escaped symbol)?

I repeat, many implementations *aren't* standard conforming because 
of control character conflicts.  I think an implementation should
make a deliberate effort to keep such non-standard behavior to a
minimum.

-- 
J. Giles
Newsgroups: comp.lang.fortran
From: r-larkin@uiuc.edu (Ron Larkin)
Subject: Re: Adjustable arrays
Organization: Illinois Natural History Survey
Date: Tue, 6 Oct 1992 00:54:14 GMT

In article <1aq7reINNsqq@early-bird.think.com> sandee@Think.COM (Daan Sandee)
writes:
(concerning article <EJH.92Oct5134025@khonshu.colorado.edu>, by
ejh@khonshu.colorado.edu (Edward J. Hartnett)) [with some stuff deleted]

>Older versions of Fortran (Fortran 66 or even older) didn't have a 
>declaration of the form v(*)....  So the common dodge
>was to declare all such arrays as dimension v(1). This always works - for
>single-dimension arrays and for the last (rightmost) dimension of a multi-
>dimensional array.... 

   Not quite.  There were some compilers that saw the V(1) and were so very
clever that they stored them as variables, not arrays, because they had only
one element.  Then further into the module these compilers would complain if
one referenced any element >1.  So many of us took to declaring an array in a
subprogram as V(2) instead of V(1).
   These outdated practices are not necessarily products of stupidity,
sometimes merely quaintness.

Ronald P. Larkin, Illinois Natural History Survey
607 E. Peabody Drive, Champaign, IL 61820  USA
r-larkin@uiuc.edu (Ron Larkin)
Newsgroups: comp.lang.fortran
From: bauwens@acs.ucalgary.ca (Luc Bauwens)
Subject: Re: How do I make MS Fortran 5.1 use lots of memory?
Date: Thu, 01 Oct 92 23:08:24 GMT
Organization: The University of Calgary, Alberta

In article <1992Sep30.202817.6122@tc.cornell.edu> bai@msiadmin.cit.cornell.edu (Dov Bai-MSI Visitor) writes:
>In article <25715@oasys.dt.navy.mil> ruckman@oasys.dt.navy.mil (Christopher Ruckman) writes:
>>Can someone help me figure out how to compile/link my program and run
>>it under DOS using MS FORTRAN 5.1, pleeeeze!  I've spent hours thumbing
>>through the manuals, but I just can't seem to figure it out!
>>
>>I have a 486-50 with 16MB of RAM.  The program source code is about
>>2000 lines, and includes lots of real*8 and complex*16.  The biggest
>>array is something like 130 by 37 (complex*16).  I'd be glad to elaborate
>>if that's not enough info.
>
>Let's see:
>   Number of bytes for largest array is:
>       130 * 37 * 16 * 2 = 153920 > 64k.
>
>Looks like you are still below the DOS 640k limit, but your big array
>is larger than 1 segment (64k). You should either declare this array
>with the [HUGE] attribute, or to avoid playing with segments just
>compile it with the HUGE memory model. Add the /AH compiler switch
>in compilation. The default is /AL, the large memory model.
 
Yes, but it wouldn't take many of those to hit the 640 k
limit right away, especially with the 2000 lines of code.

So, chances the 640 k are part of his problem too.

>If you hit in the future the DOS 640k limit, you can still use 
>the compiler under OS/2 and it would let you address 16M. I think
>that Ver. 5.1 works also under MS-WINDOWS which may also let you
>use the extended memory. 

Or under OS/2.

Or get a Watcom 386 compiler.  It comes with a DOS extender that will
access most of his memory under DOS, if he doesn't want to
use Windows or OS/2.  But I find it much nicer to compile
in the OS/2 environment.  The compiler will probably have
to do lots of swapping to disk if it got to live in a 640k
environment.

Luc B
From: zkdc05@trc.amoco.com (Kelly D. Crawford)
Newsgroups: comp.lang.fortran
Subject: Re: Is this a Compiler Bug ?
Date: 1 Oct 92 22:03:26 GMT
Organization: Amoco Production Company, Tulsa Research
Originator: zkdc05@church


In article <1992Oct1.195512.16735@chpc.utexas.edu>, ivab015@hermes.chpc.utexas.edu (Albert Wu) writes:
> The following program cannot be compiled by fortran compilers on a Sun as well
> as on a RS6000.  Apparently, the backslash is treated as a continuation
> symbol.  Is this considered a bug in this program or a bug in the compiler.
> 
>       program test
> 
>       character*30 string
> 
>       string = '1234567890123456\8901234567890'
>       ibksl = index ( string, '\' )
>       print *, 'ibksl=',ibksl
> 
>       end

The \ character is used as an escape in Unix.  To use the \ character,
use '\\' as in:

       string = '1234567890123456\\8901234567890'
       ibksl = index ( string, '\\' )

Kelly
-- 
Kelly D. Crawford             | Amoco Production Research | These are my own
kcrawford@trc.amoco.com       | 4502 East 41st Street     | opinions, not
phone: (918) 660-4043         | Tulsa, OK  74102          | Amoco's...
          >>> *** This line intentionally left blank *** <<<
Newsgroups: comp.lang.fortran
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.lang.fortran,comp.std.misc
Subject: ANSI FORTRAN 77 -- Obscure Question on Interpretation
Date: 3 Oct 92 08:16:12 GMT
Followup-To: comp.lang.fortran
Distribution: comp
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139

For those who are language lawyers, standards studs, whatever, dig out
your ANSI FORTRAN 77 standard and see if you can answer this question:

Is the following program standard-conforming with regard to the SAVE
status of the COMMON area named FOO?

      PROGRAM HUH
C
C Being in a main program unit, /FOO/ is, in an implementation sense,
C always SAVEd.
C
      COMMON /FOO/ X
      ...
      END

      SUBROUTINE HI
C
C Here, /FOO/ isn't SAVEd.
C
      COMMON /FOO/ X
      ...
      END

      SUBROUTINE THERE
C
C Here, /FOO/ is SAVEd.
C
      COMMON /FOO/ X
      SAVE /FOO/
      ...
      END

The standard seems pretty clear on this point: if COMMON /FOO/ wasn't
mentioned in the main program unit (PROGRAM HUH), then the program would
_not_ be standard-conforming because it says that if one program unit
SAVEs a named COMMON, _all_ program units that mention that COMMON area
must SAVE it.

However, when the main program unit mentions COMMON /FOO/, it is hard for
me to be sure whether that means the other program units may now disagree
as to whether it is SAVEd or not (since it is automatically SAVEd by being
mentioned in HUH), or whether they must be consistent and SAVE it.  (Or
can they at least be consistent and _not_ SAVE it?)

Of course, this shouldn't normally have any practical effect on programs
in modern machines, but then again, a huge COMMON area might be an excuse
for a dynamic allocation mechanism permitted by the lack of SAVE (assuming
a compiler option to enable this dangerous feature, given how few
programmers use SAVE when they're supposed to).

In any case, for GNU Fortran, I'd like to know whether to issue a warning
in this case (when the -incredibly-nitpickingly-pedantic option is
specified on the command line...twice :-).

Send me email as to your opinion (i.e. how you read which parts of the
standard), and I'll summarize if there seems to be enough interest.

Also, I don't have time right now to look at the Fortran 90 standard, but
if anyone does, is it clearer, less clear, or what on this issue?  Maybe
we should send email to f90interp or whatever that address is (I've got
it around here somewhere...).

Thanks in advance!
--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)