HDTenEightyP/NetNews huggingface dataset:
From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: Format of unformatted files: does a standard exist?
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Tue, 14 Apr 92 15:16:22 GMT


In article <1992Apr12.202004.25537@ux1.cso.uiuc.edu>, 
ercolessi@uimrl7.mrl.uiuc.edu  (Furio Ercolessi) writes:
>
|>Sure.  I was just wondering if vendors could agree on an unofficial
|>"de facto" standard, within the limited but growing subset of
|>machines with IEEE arithmetics under a Unix or Unix-like operating
|>system.  As a user, I much appreciate that IBM (on RISCs), Silicon
|>Graphics, Sun, Hewlett-Packard and Stardent could agree on the
|>same format, without any official standard forcing them to do so.
|>

They have.  The ACE (Advanced Computing Environment) initiative, a multi-vendor
group, has agreed on little-endian byte addressing and IEEE floating, the same 
as is implemented in all of the Intel chip-based PCs, DEC MIPS-based 
workstations and forthcoming DEC Alpha-based systems.  I just read in Digital 
News that MIPS has released its own ARC (one of two ACE-specified architectures,
the other being the Intel x86 series) compliant workstation which uses
little-endian byte ordering.   More will follow from various vendors.

I think this is a big win for users, in that there will be common data formats
between the millions of PCs in use today, workstations and larger systems.
--

Steve Lionel                    lionel@quark.enet.dec.com
Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
From: ajayshah@alhena.usc.edu (Ajay Shah)
Newsgroups: comp.lang.fortran
Subject: Re: PD Fortran Compiler
Date: 8 Apr 1992 18:45:14 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: alhena.usc.edu

hoffmann@pandanus.cs.ntu.edu.au (Arthur Hoffmann) writes:
> I just would like to know if there is any Fortran PD or ShareWare Compiler around? 

There is a project underway to write a fortran frontend to gcc.
But generally hackers (the kind who write free programs) don't
take too much interest in fortran.

There is
        (a) a great free C compiler and
        (b) a great fortran to C translator.

By hooking them up you could be flying nicely.
The free cc is GNU cc.
The free fortran-to-C is f2c.  It's written in C (of course) so you need
a C compiler to compile it.

        -ans.
-- 

Ajay Shah, (213)749-8133, ajayshah@usc.edu
Newsgroups: comp.lang.fortran
From: cowan@impec.zko.dec.com (Ken Cowan)
Subject: Re: Format of unformatted files: does a standard exist?
Reply-To: cowan@impec.zko.dec.com (Ken Cowan)
Organization: Digital Equipment Corporation
Date: Tue, 14 Apr 92 14:32:46 GMT

In article <1992Apr9.054051.21932@ux1.cso.uiuc.edu>, ercolessi@uimrl7.mrl.uiuc.edu  writes:
|>
|>I have investigated a bit the compatibility of unformatted
|>Fortran files between different Unix machines.  This is a very
|>interesting issue if you think of installing NFS (any machine
|>can read any file??? sounds too good to be true...).  But is
|>also important if you just want to move unformatted data
|>between two boxes.  It is the classic tiny thing that is
|>overlooked when buying, but that then can affect your life
|>immensely!

   DEC Fortran for Risc/Ultrix has a switch -assume big_endian that lets 
it read big endian data .   It's documented in the man page, release notes (in V3.0)
and User's Manual (V3.1).  

   -assume big_endian only works if the unformatted read knows what the
true datatype is.  If you read data as an array of integers and equivalence it to
real's, character strings, etc, then you don't get the right thing happening.
As an aside, it also handles VAX, IBM and CRAY floating point formats.

	KC
From: shawn@ut-emx.uucp (Shawn Boyd)
Newsgroups: comp.lang.fortran
Subject: Re: 'Q' format specification
Date: 9 Apr 92 18:39:25 GMT
Organization: The University of Texas at Austin; Austin, Texas

In article <11930@tamsun.tamu.edu> potter@scan2.tamu.edu writes:

>Greetings:
>
>	Here's a question you FORTRAN gurus ought to be able to knock out
>pretty quick.  I'm using a VAX 3100 workstation with DEC Fortran (not sure
>what version). The code I'm trying to interpret uses a 'Q' format specification
>on some of the read statements. I've never heard of a Q specification and can't
>find anything about it in any of my F77 reference books. Here's the subroutine:
>
>	SUBROUTINE I4READ(file, IX)
>    1	READ (FILE, 10, ERR=100, END=200) IQ, IDUM
>   10   FORMAT(Q, I10)
>	IF(IQ.NE.0) IX=IDUM
>     	RETURN
>  100   WRITE(file, 150)
>  150   FORMAT( '$error during read, try again: ')
>	GOTO 1
>  200   WRITE(file, 250)
>  250   FORMAT( '$eof during read, try again: ')
>        GOTO 1
>        END
>
>	I cannot at all understand what that stupid Q is doing there.  As near
>as I can tell the input at that point consists of only 1 float number no bigger
>than 5 or 6 significant digits (at the most).  If anyone please has any clue
>as to what this silly Q means, PLEASE let me know.  Thanks,
>						
>						Shane Potter
>						potter@scan2.tamu.edu
>						Texas A & M University
>						Cyclotron Institute

 Hi Shane;
  
 The following is paraphrased from the VAX FORTRAN Volume 2 Reference Manual,
 section 8.3.12.1, p. 8-37.  It is an extension to the ANSI 77 level standard,
 and as such, probably won't be found in any texts dealing strictly with the 
 X3J3 subcommitte's specifications.  As you may know, Fortran 77 is described
 by that committee as a "permissive standard" meanining that extensions are 
 considered to be OK.  This has allowed Fortran to grow as a language over the
 past years, but has caused some minor (or, in the opinion of some people) 
 major readability problems. 

 The 'Q' edit descriptor obtains the number of characters in the input record
 remaining to be transferred during a read operation, and causes that number 
 to be stored in the corresponding I/O list element.  
 
 For instance: the following I/O statements...

       READ (1, 100) A, I, NCHARS, (LINE(I), I=1,NCHARS)
   100 FORMAT (F10.4, I5, Q, 80A1)

 will read the first 15 characters of the corresponding input record into 
 the variables "A", then "I", then determine the number of remaining characters
 in the record into "NCHARS", then put the remaining characters in the record 
 into the vector "LINE".  The corresponding I/O list element (namely NCHARS)
 must be of type integer or logical.  Personally, I'd use type integer.

 There you have it.  Hope this helps.

 Shawn Boyd 
 Unix/VMS Consulting
 Computation Center
 University of Texas at Austin -- or, as you guys like to say, "TU"  ;^)   
 shawn@utxvms.cc.utexas.edu

 P.S. Say, did they really make you guys quit having "the bonfire?"
From: pld@hpfcso.FC.HP.COM (Paul Dineen)
Date: Thu, 9 Apr 1992 01:15:51 GMT
Subject: Re: Q format specification
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lang.fortran

> >It's a VAX extension, it is not in the F77 standard and as
> >far as I can see it's not in the new F90 standard.
>
> It is however in Silicon Graphics UNIX f77 

 And HP.
Newsgroups: comp.lang.fortran
From: jps@netcom.com (John Serafin)
Subject: problems compiling libi77 from f2c under DJGPP
Date: Tue, 14 Apr 92 01:33:16 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Summary: err.c and others bomb in djgpp include files
Keywords: f2c DJGPP library

I can't get several of the libi77 files from f2c to compile under 
DJGPP 1.05; the trouble seems to be with the include files supplied
with DJGPP.   As an example, I get the following error for err.c
-------
In file included from g:/gc/include/fcntl.h:46, from err.c:7:
g:/gc/include/std.h:43: parse error before `int'
-------
Can someone help with this?   There was a recent post saying that there
was no problem in the port.   Is there an ftp site with DJGPP forms of
the f2c libi77.a and libf77.a ?

-- 
John P. Serafin  |  Operating a bicycle is more like driving than riding.
jps@netcom.com   |  Operating an automobile is more like riding than driving.
From: fink@Think.COM (Paul Fink)
Newsgroups: comp.lang.fortran
Subject: Re: Dear 8mm guru
Date: 15 Apr 1992 17:56:41 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world
NNTP-Posting-Host: custard.think.com

In article <1992Apr14.183220.9848@nsisrv.gsfc.nasa.gov>, schieb@isis.gsfc.nasa.gov (Brian D. Schieber) writes:
|> wrong newsgroup probably but...
|> 
|> I have a slew of 8mm backup tapes that have been set aside
|> because of repeated errors in backups. The whole backup 
|> mechanism on our VAXes is flaky and I'd like to confirm or
|> deny the integrity of the tapes. 
|> 
|> Does anyone know of a method/utility that could check out
|> these tapes?
|> 
|> Thanks ahead of time,
|>  Brian

  8mm tapes are known for failing. I would strongly suggest that you
  throw the failed tape away. Some systems do have a verify option that
  can be used to crudely test tapes. But 8mm tapes will fail at random
  times. Some 8mm tape drives are also know for failures.

  Actually you may get better information if you move your posting to a
  group that concerns system administration, or the hardware &
  operating system you are using.


Newsgroups: comp.lang.fortran
From: miker@metaware.metaware.com (Mike Ross)
Subject: FORTRAN validation suite
Reply-To: miker@metaware.UUCP ()
Organization: Metaware Incorporated, Santa Cruz, CA
Distribution: ca
Date: Mon, 6 Apr 92 16:35:39 GMT

Pardon if this is an FAQ, but I need to obtain an
official copy of the latest FORTRAN GSA validation
suite, even if (as I assume) it still only covers
FORTRAN-77. Can someone give me an address and phone
number for where to obtain the suite? Thanks in advance.
		  Mike
From: klassen@sol.UVic.CA (Melvin Klassen)
Newsgroups: comp.lang.fortran
Subject: Re: Substring assignment -- F77 vs F90
Date: 14 Apr 92 17:31:23 GMT
Organization: University of Victoria, Victoria, B.C. CANADA

In article <*> mcdowell@cfa.harvard.edu (Jonathan McDowell) writes:
>
>  CHARACTER*4 A
>  A='1234'
>  A(2:)=A
   ???????

10.4 __Character_Assignment_Statement__

The form of a character assignment statement is:
 
	V = E

where V is the name of a character variable, character array element,
        or character substring
 
      E is a character expression
 
Execution of a character assignment statement causes the evaluation
of the expression E and the assignment and definition of V with the
value of E.  None of the character positions being defined in V may 
be referenced in E. ...
 
!! Read that last sentence again.
!! The above program is **NOT** "standard-conforming" Fortran-77.
From: peterson@grue.enet.dec.com (Bob Peterson)
Newsgroups: comp.lang.fortran
Subject: Re: VAX VMS Fortran -> UNIX Fortran?
Keywords: VMS Fortran
Date: 9 Apr 92 21:50:50 GMT
Reply-To: peterson@tle.enet.dec.com
Distribution: usa
Organization: Digital Equipment Corporation


In article <ccpj40g.tcumming@netcom.com>, tcumming@netcom.com (Tom Cumming) 
writes:
>    I have literally megabytes of VMS fortran source that I would like
>to compile on my UNIX machine (somehow). The fortran source contains a
>lot of non-f77 things like structures, unions, records, etc. Is there any
>way to compile this stuff on a UNIX machine? So far, I'm thinking of
>adding these VMS fortran extentions to f2c (a fortran to C preprocessor)
>but I would like to know if anyone has any better ideas first.

VAX FORTRAN and DEC Fortran are just about as close as anyone in the 
world can get to such compatibility, right down to the odd commas, FORMAT 
syntax, and semantics.  They run on VAX ULTRIX and RISC ULTRIX/OSF, 
respectively.  The former compiler *is* VAX FORTRAN, the latter is a 
rewrite using the VAX FORTRAN sources.

\bob
From: noam@ooc.uva.nl (Noam Kloos)
Newsgroups: comp.lang.fortran
Subject: my problem is solved
Keywords: FORTRAN77 READ WRITE FORMAT
Date: 13 Apr 92 23:42:53 GMT
Organization: Center for Innovation and Cooperative Technology, University of Amsterdam

I received a lot of possible solutions to my problem.
Many people got upset by my typing error being
READ(1,99) WRITE(1,99) which should be READ(1,99) WRITE(6,99)
Anyhow what all said is true, I had to use TWO DIFFERENT FORMAT statements.
Some suggested for the WRITE FORMAT(1X,A80) others (' ',A80)
or (1H ,A80), but that all resulted in double spacing my output.
What bugs me again is that inspired to this feedback I tried
(1H+,A80) what should mean overwriting text, but no this is actually the
solution to the problem with my MS FORTRAN77 ver 4.1

Greetings,
Noam Kloos.
General engeneer.
From: weinri@athena.cs.uga.edu (Kevin Weinrich)
Newsgroups: comp.lang.fortran
Subject: FORT Integer Programming Software desired
Date: 16 Apr 92 15:57:14 GMT
Organization: University of Georgia, Athens

I apologize if this is a FAQ; I couldn't find a FAQ list in my news reader.
Directions to the nearest FAQ list most appreciated.

I'm looking for a public domain Integer Programming package/library.  Would
you tell me the names of the best ones (I should be able to locate them
through Archie once I have the names)?  I'm using SUN FORTRAN on a SPARC.

Thanks kindly,
Kevin Weinrich
weinri@athena.cs.uga.edu
From: wjb5106@zeus.tamu.edu (Walter Barnett)
Newsgroups: comp.lang.fortran
Subject: Re: 'Q' format specification
Date: 7 Apr 92 00:44:00 GMT
Organization: Texas A&M University
News-Software: VAX/VMS VNEWS 1.41

In article <11930@tamsun.tamu.edu>, potter@scan2.tamu.edu writes...
>Greetings:
> 
>	Here's a question you FORTRAN gurus ought to be able to knock out
>pretty quick.  I'm using a VAX 3100 workstation with DEC Fortran (not sure
>what version).  The code I'm trying to interpret uses a 'Q' format specification

Here's what the Help facility has to say about it:

FORTRAN

  Format_Specifiers

    Q

       (Query Remaining Character Count)

       On input, obtains the number of characters remaining in the input
       record to be transferred during a read operation.  The following
       example uses the Q descriptor to determine the size of the input
       record:

       READ(5,'(Q,A)') LEN, REC(1:LEN)

       On output, the Q descriptor has no effect, except that the
       corresponding I/O item is skipped.

FORTRAN Format_Specifiers Subtopic?
_______________________________________________________________________
Walter Barnett        Aerospace Engineering        Texas A&M University
From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup)
Newsgroups: comp.lang.fortran
Subject: Re: C routines in FORTRAN ?
Date: 16 Apr 92 16:47:34 GMT
Organization: Sun MegaSystems
NNTP-Posting-Host: chiba
In-reply-to: proffen@bl.physik.tu-muenchen.de's message of 16 Apr 92 16:18:04 GMT


In article <proffen.703441084@sally> proffen@bl.physik.tu-muenchen.de (Thomas Proffen) writes:

   Who can help ....  :-)

If you can dig up a copy of the document:

              800-5302-10 - User's Guide, Sun Fortran 1.4

I think you will find the answers to your questions in gory detail.
--
----------------------------------------------------------------
Keith H. Bierman    keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM
SunPro 2550 Garcia MTV 12-33             | (415 336 2648)   
Mountain View, CA 94043  <speaking for myself, not Sun*> Copyright 1992
Newsgroups: comp.lang.fortran
From: tholen@galileo.ifa.hawaii.edu (Dave Tholen)
Subject: Re: Best compiler for a 386 (DOS/OS2v2)?
Organization: University of Hawaii
Date: Thu, 16 Apr 1992 08:03:43 GMT

Dov Bai writes:

> Actually, I am not sure about the 1GB limit. There has been a discussion
> a while ago in the comp.os.os2.misc group about OS/2 being able to address
> more than 16M, and some people claimed that it is only on none ISA buses
> (i.e. Micro-channel Architecture or EISA). I dont know if they are right.

Under OS/2 version 1.X, the limit was 16 Mbytes.  Under OS/2 version 2.0,
the per-process limit is 512 Mbytes, but I understand that the next
version will raise the limit to 2 Gbytes.  The full 4 Gbytes that 32 bits
can address isn't quite available, because they apparently need one or
more of those bits to translate 16-bit addresses into 32-bit addresses and
vice versa (needed for DOS, Windows, and OS/2 version 1.X support).

Whether the hardware underlying the operating system imposes its own limit
isn't something I'm in a very good position to address, but OS/2 is not
the limiting factor.
From: dappel@grafted.UUCP (Dave Appel)
Newsgroups: comp.lang.fortran
Subject: Re: BASIC to Fortran converter
Date: 16 Apr 92 08:13:29 GMT
Organization: GRAFTED, Central Indiana's Usenet BBS 317-881-4369

smadden@titan.trl.OZ.AU (Steve Madden) writes:
> We too would be interested in such a beast, as there is here a considerable
> ammount of BASIC code which we would like to convert to Fortran (C might do a
> a pinch, but fortran much preferred). So if anyone out there can answer the
> above question, that's at least two of us who'd be grateful :)
> 
> ---------------------------------------------------------------------------
>                                    |                |                     |
> Steve Madden                       | The opinions   |                     |
> Telecom Research Laboratories      | contained      |      ______ _       |
> 770 Blackburn Road                 | herein are mine|        /   / >  /   |
> Clayton                            | alone (so you  |       /   /--  /    |
> Victoria 3168                      | know who to    |      /   /  \ /__   |
> Australia                          | blame !!)      |                     |
> Tel 613 253 6629, Fax 613 253 6339 |                |                     |
> ___________________________________|________________|_____________________|

If you're willing to hire a contractor, I'd be willing
to convert BASIC (either BASICA or GW-BASIC or QuickBasic)
to Microsoft Quick-C using either vanilla ANSI C or
MS Extensions.  I could do BASIC -> Fortran, but don't 
currently have a fortran compiler on site.
for a small up-front fee to buy the compiler, I could
convert it to Fortran, or any other flavor of C that runs
on a 80x86 based PC.
 
The origin of this message cannot receive email.  
My "real" email address is:
    dave.appel@f30.n231.z1.fidonet.org


--
Dave Appel
The Grafted Branch BBS
317-881-4369
internet: dappel@grafted.UUCP
uucp: ..!uunet!grafted.UUCP!dappel
 = = Grafted Branch BBS (317) 889-6997 2 Gig on-line = =
From: Clifford.J.Walinsky@dartmouth.edu (Clifford J. Walinsky)
Newsgroups: comp.lang.fortran
Subject: Fortran-90 Copy Propagation on Arrays
Date: 7 Apr 92 19:53:40 GMT
Organization: Dartmouth College, Hanover, NH

I am exploring an extension of the copy propagation optimization to
Fortran-90.  Conventionally, copy propagation is conducted on scalars. 
Fortran-90's array assignment features provide additional opportunities
for copy propagation.  Here is an example (somewhat contrived) of
statements that concatenate 2 vectors, and reverse the result:
  FORALL(i=1:M)
 $ C[i] = A[i]
  FORALL(i=M+1:M+N)
 $ C[i] = B[i - M]
  FORALL(i = 1:M+N)
 $ D[i] = C[(M+N) - i + 1]
With some enhanced copy propagation and dead-code elimination, which
work across FORALL loops, the following statements could be produced:
  FORALL(i = N+1:M+N)
 $ D[i] = A[(M+N) - i + 1]
  FORALL(i = 1:N)
 $ D[i] = B[N - i + 1]
Are there Fortran-90 compilers (experimental/planned/in-use) that
perform this kind of analysis?
Thanks for your help.

Please reply to:
Clifford Walinsky
Dept. Math & CS
Dartmouth College
cliffw@dartmouth.edu
Newsgroups: comp.lang.c,comp.sys.mac.programmer
From: Pete Harlan <harlan@copper.ucs.indiana.edu>
Subject: Re: Problem De-allocating Memory in variable sized arrays
Organization: Indiana University
Date: Wed, 8 Apr 1992 05:25:53 -0500

[Note: I followed up to this article once already in a totally idiotic
fashion, not having properly examined the code.  I cancelled it, but
if you read it please ignore it...]

In <1992Apr1.222646.10433@coe.montana.edu> umsfjban@bill.oscs.montana.edu (Jeff Banfield) writes:

|void allocateDATA (void)
|{
|	register i;

|	DATA = (unsigned char **) NewPtr(NROW * sizeof(unsigned char *));
|	DATA -= 1;	/* to allow indexing starting at 1 */

|	for (i = 1; i <= NROW; i++){
|	    DATA[i] = (unsigned char *) NewPtr(NCOL * sizeof(unsigned char));
|	    DATA[i] -= 1;  /* to allow indexing starting at 1 */
|	}
|}

Okay, this is really pretty nifty, excepting for the fact, pointed out
by Steve Creps, that having a pointer to the 'element' before the
first element of an array might cause you problems (such as it
wrapping around to being a huge number, but even that might not cause
a problem).  (Actually, since NewPtr probably has some housekeeping
stuff before the actual allocated memory, as long as your element size
is small enough I'm sure you'll be okay.)

|However if I give the commands

|	allocateDATA();
|... heap size decreases
|	fillDATA();
|... which runs through the open file dialog, reads in a file and puts
|... the results into DATA, the heap size doesn't change ... which it's
|... not supposed to do since I've already allocated the memory.

|Now if I call
|	freeDATA();
|... and check the heap size it doesn't change ... it's as though I never
|... freed the data.


It would seem as if there's a problem with your fillDATA() routine.


Would it be possible, with real (e.g., not Think C) C++ to define a
class that is a 1-based array, and define the various operators on it
(e.g., [], dereferencing, +) so they would convert it back to 0-based,
and also define the casts to and from 0-based arrays, so that it would
be impossible to make a mistake when passing arrays to and from
routines that operate on 1-based arrays?  (The compiler would
automatically convert if a routine that was declared to take an object
of type 1-based-array were passed an ordinary C-based array, and
vice-versa.)

A friend has suggested doing this to interface code written to work
with 1-based X-Y coordinates with routines that expect 0-based
coordinates, and it seems that perhaps it could be beneficial here.

Of course, sticking to the C paradigm of 0-based arrays will not only
help your code work with more C code, but will also make it more
readable to others (such as simpletons like myself who didn't look at
it closely enough when you posted it).

--Pete Harlan
  harlan@copper.ucs.indiana.edu
From: eric@pencom.com
Newsgroups: comp.lang.c
Subject: Re: Is the address of a global a constant?
Date: 8 Apr 92 13:55:55 GMT
Organization: Pencom Software

> Unless the standard turned around and did something completely
> different from what is in K&R, I highly doubt that "the address of an
> object with static duration is ALWAYS a constant.".  I agree that it
> is not an integral constant expression; but what is this?
> 
> case &y - &z:

You are not allowed to subtract pointers to different data segments.
The compiler may let you, but ........
From: herzog@ux5.lbl.gov (Hanan Herzog)
Newsgroups: comp.lang.c
Subject: Re: C Books
Date: 8 Apr 92 23:02:16 GMT
Article-I.D.: overload.1992Apr8.230216.3376
Reply-To: herzog@ux5.lbl.gov (Hanan Herzog)
Organization: Lawrence Berkeley Laboratory

If you have some past programming experience and want a thourough C
book I would strongly reccomend, "The C Porgramming Language", by
Kernighan and Ritchie - Prentice Hall. The authors practically
invented the language.  The book is compact and costs a few bucks more
than many other C books you'll find. But it's worth it. It is also
a favourite at many universities. It's a classic and probably the single
best computer book in existence. Chck it out!


Hanan
-- 

email:
	herzog@lbl.gov
Newsgroups: comp.lang.c,comp.programming